Today, the "Upload Last Build" feature of Visual Micro for VS 2019 stopped working.  The "Micro Build" Output is like that shown below.
Before selecting "Upload Last Build", I can see in the build folder that the last build happened and there are the appropriate .bin files.
After selecting "Upload Last Build" all the files in the build folder get deleted (which should not occur!) so of course the upload then fails.

This feature used to work great but now it is broken.

I was using build 2025_0120_1900 so I just upgraded to 2025_0314_1900.  However, the problem persists.

Any advice on what has gone wrong and how to fix the problem?

------------------------
Uploader started for board ESP32 Dev Module(esp32_esp32)
Upload method will be: bootloader
Uploading via Bootloader 
ool.exe --chip esp32 --port "COM7" --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 80m --flash_size 4MB 0x1000 .ino.bootloader.bin" 0x8000 .ino.partitions.bin" 0xe000 s/partitions/boot_app0.bin" 0x10000 .ino.bin"
usage: esptool write_flash [-h] [--erase-all]
                           [--flash_freq {keep,80m,60m,48m,40m,30m,26m,24m,20m,16m,15m,12m}]
                           [--flash_mode {keep,qio,qout,dio,dout}]
The uploader process failed
                           [--flash_size {detect,keep,256KB,512KB,1MB,2MB,2MB-c1,4MB,4MB-c1,8MB,16MB,32MB,64MB,128MB}]
                           [--spi-connection SPI_CONNECTION] [--no-progress]
                           [--verify] [--encrypt]
                           [--encrypt-files <address> <filename> [<address> <filename> ...]]
                           [--ignore-flash-encryption-efuse-setting] [--force]
                           [--compress | --no-compress]
                           <address> <filename> [<address> <filename> ...]
esptool write_flash: error: argument <address> <filename>: [Errno 2] No such file or directory: .ino.bootloader.bin'
------------------------

Thank you for that response.  When I made my post, the "error" was happening very frequently (but not every time).  While waiting for your thoughts, I did other (non Visual Micro related) work.  After your response, I went back to gather the build data you requested but I could not replicate the error - very frustrating.   

I can watch for it to recur but it means that I will have always do a build and then a separate "upload last build".  This also means that I will always need to save to a file every build in the hopes that the subsequent "upload last build" gives the error.  That is starting to sound tedious.  Is there a way to have Visual Micro save the output of each build to a separate log file?  If so, then I can do that and, when the "upload last build" error occurs again, I can just send the most recent build log that is associated with that error.

Please let me know if that is a possibility.

Related question:   

What would cause the "upload last build" feature to delete files in the build folder (For me, using an ESP32 board in Windows, that is the "C:\Users\[username]\AppData\Local\Temp\VMBuilds\[SolutionName]\esp32_esp32\[SolutionConfigurationName]\" folder.   

Normally, the only time I see files disappear from the [SolutionConfigurationName] folder is when I use the Visual Studio "Build > Clean Solution" menu sequence.  Does the "upload last build" feature do some kind of check and then sometimes trigger a "Clean Solution"?  At least that is what it looked like to me.

None of the changes you described were done.

One thing that might have been different is that I might have had the option "Save Board, Port and Programmer For Each Configuration" on (I normally have it off).  However I have since then tried "Upload Last Build" with that option both on and off and the "Upload Last Build" worked so that is not, by itself at least, the problem.

Another thing that may be a factor is that I use custom Visual Studio Build Configurations (not "Release" and "Debug" but instead things like "BuildVariant_1" and "BuildVariant_2") to manage the builds on different variants of the same project.  This creates the following types of Visual Micro build paths:

"C:\Users\[username]\AppData\Local\Temp\VMBuilds\Project_A\esp32_esp32\BuildVariant_1\"
"C:\Users\[username]\AppData\Local\Temp\VMBuilds\Project_A\esp32_esp32\BuildVariant_2\"

This approach prevents the various builds from overwriting each other.  To be clear, the differences in the build variants is in my code, NOT in how Visual Micro is configured.  In all cases, I use the same Visual Micro configuration (including the board package, board options, etc. - yes, I know that above I indicated I was trying out the "Save Board, Port and Programmer For Each Configuration" feature at one point but I stopped because I was never actually changing said configuration).

This use of different Visual Studio Build Configurations is a good strategy for my use case though I suspect it may not be commonly used so it is an area you might look at for tracking down this "Upload Last Build" failure issue.

I will email you the Build_Output.txt and Upload_Last_Build_Output.txt files separately.