I find myself rather frequently using "Rescan toolchains and libraries" from the Micro Menu/General popup menu.
Then, I HAVE to click "Clean Solution" from the Visual Studio top-level "Build" menu. Next, I have to click the Build & Upload menu item or toolbar button.
Rather uncomfortable - the most time in this whole operation is on the poor user, the computer completes the intermediate steps rather instantly
Could you please provide some integral shortcut functions for this?
Btw, I'm am not paranoid, but at least on the ESP8266 developing a library requires REBUILDs all the time, or the changes don't get picked up by the linker properly

Additional information: The ESP8266 intrinsic libraries, and there's quite a few of them, use in their library.properties:

dot_a_linkage=true

Maybe there's a bug in the dependency tree?

Pls read prev note but just a thought that maybe the cache is playing up with dot_a_linkage

Q:
Can you pls give small zip with simple example that fails in a solution with 1) shared library and 1) arduino project.

Q:
+ Assuming you do have a "references>shared project reference" from the arduino project to the lib?

Thanks

It sounds like just an issue with dot_a_linkage libs not releasing cache when you make manual changes to library code. WQe can look into that. Otherwise you are saying that it is identical.

However if you are adding new files to libraries, sounds like you are not then in visual micro you will need to use the create shared libtrary option so the new files are detected. It doesn't sound like you are creating new files in libraries so maybe you can ignore.

You are wrong about the usage of menus. The short cut keys on the Build and the Debug menu can all be used. As I said it's the same. Debug>Start F5 is compile and upload , same as Debug>Start without debugging. You will see that "Build" is CTRL+SHIFT+B

File>Open Project and File>Open Solution or File>New>Project also work, again you do not need to use the vMicro menu.

All vMicro menus and buttons can be placed anywhere in the IDE menus and bars, using the standard Customization option in Visual Studio.

Adding a shared library has other advantages. It gives intellisense specific to the currently selected board of the Arduino project. It also allows you to build your own list of libraries (even multiple versions of same library) in a location outside of the standard arduino library locations. This is important if you edit the libraries you do not want your modifications to be lost when you allow arduino or visual micro update/install new library version.

As I said, I will look at the issue if it is just the dot-a-linkage but I think you could review my answer in more depth and learn some things. The arduino ide is quite slow when you click build, this is because it has to re-read everything. The functionality in visual micro gives best speed, most flexibility and better protection of your changes.

The latest release of visual micro also supports auto creation of cloned library versions for Solution or Project but you can use the same system to create your own master list of shared libraries in any folder or folders that you want. Then you can share libraries in a single solution or for multiple solutions without our code breaking in the future after arduino update.

It's worth looking into shared libraries, especially for library coders.

I am not seeing an issue, we might need to look to see if you have changed the cache settings in F4 project properties or global options? or maybe I haven't set the test up very well.

If you see the yellow box above it shows how to switch on verbose compile. This shows us more clearly when a library is recompiled.

For my test I select any old library (AccelStepper) and switched on dot-a-linkage for the library.

I did not use the option to add as a shared library so the #include in my .ino file was the only reference to the library.

I also opened a .cpp file from the library so that I could make a change. Then when I clicked build I could see the change had been detected and the .a archive recreated like this.

Using library AccelStepper version 1.58 in folder "file:///C:/Users/tl/Documents/Arduino/libraries/AccelStepper"
  Using previously compiled file: AccelStepper.cpp.o
\2.5.0-3-20ed2b9/bin/xtensa-lx106-elf-g++" -D__ets__ -DICACHE_FLASH -U__STRICT_ANSI__ ools/sdk/include" ools/sdk/lwip2/include" ools/sdk/libc/xtensa-lx106-elf/include" "-ID:\System\WinTemp\VMBuilds\Dot_a_link_test\esp8266_generic\Release/core" -c -w -Os -g -mlongcalls -mtext-section-literals -fno-rtti -falign-functions=4 -std=c++11 -MMD -ffunction-sections -fdata-sections -fno-exceptions -DNONOSDK221=1 -DF_CPU=80000000L -DLWIP_OPEN_SRC -DTCP_MSS=536 -DLWIP_FEATURES=1 -DLWIP_IPV6=0 -DARDUINO=10809 -DARDUINO_ESP8266_GENERIC -DARDUINO_ARCH_ESP8266 -DARDUINO_BOARD=\"ESP8266_GENERIC\" -DLED_BUILTIN=2 -DFLASHMODE_DOUT -DESP8266 ores\esp8266" ariants\generic" -I"C:\Users\tl\Documents\Arduino\libraries\AccelStepper\src" "C:\Users\tl\Documents\Arduino\libraries\AccelStepper\src\MultiStepper.cpp" -o \MultiStepper.cpp.o"

  Using previously compiled library archive: AccelStepper.a 

Please make a new simple test project using "File>New>Arduino Project" with empty setup() and loop() but with your library #included in the .ino code. Select your board and click build. Then make an error in your lib code and click build again. Then post the output as .txt file

Your report is a little confusing in the fact that your sketch code is acting differently but the error/change to the lib code hasn't been detected. It's possible you have two cachng issues because the .ino code shouldn't have sent any serial when you made an empty loop() and that would be unrelated to the library not being recompiled. So it is possible you options are wrong.

Let's look at the lib rebuild first and have that clear output as requested to show what is happening.

Thanks

Ah okay thanks, we will zap the .a if the lib needs rebuild.

I didn't say it was fixed I just said we now know what to fix. That message means there is no new version

However, it is now fixed in the 1908.7.2.

I am sorry, I just wanted to let you know that I might not be using the latest version - I think I remember reading something relating to rebuilds in a recent changelog.
Also, I'm not stupid, the messagebox DOES show in error, because the Visual Studio extension updates tree keeps telling me that there is a new version - perhaps you didn't update all the version tags correctly?

Current version: 1908.5.0
New version: 1908.7.0

…

Rebuilding .o files like crazy COULD be related to not updating .a archives, that why I mentioned it here.
Next issues entry is coming right away.

Except, that the VSIX installer refuses to install that either, same message box... Or wait, the box appeared, but it's updating now anyway after doing VS 2017 first (I'm actively using 2019).

I'm clearly doing QA here
Besides the oscillating build times (now another issue here as you asked for), the static archive is not rebuilt, but the .o file and the .d file are deleted, then recompiled - every other time... so sorry, I don't agree that these are different issues from my perspective...

(using the 1908.7.2 version)

OK, one step back, the archive is rebuilt EVERY time the source changes - it's just not removed on compile failure, that confused me at first. Running the compiler every time is still an issue - but for the other report, not this one, I agree.