Thanks for the report.

Were/Are all of the libraries added to the Solution as Shared Projects in any way? (they will show in Solution Explorer as one shared project per-library)

Thanks for confirming.

If the project still isn't working properly, you can send us the VCXPROJ and we can clean out the bad references so it loads correctly.

When upgrading a Shared Project library, the Shared Project needs to be removed from the Solution before updating the library (in this case the board package).  Then they can be re-added after the update is complete.

It may be better in your scenario to disable the vMicro > Add Libraries > Library Advanced > Create Shared Project When Including Libraries.   

If you wish to view the library sources easily, then the vMicro > Show/Hide Hidden files can be toggled, which will add all core and library files in use into the Solution Explorer.  The advantage of this is they are dynamically updated when the files change, or the board is reselected, so there is no manual maintenance to do.

If you need to capture and use specific versions of libraries in your projects (for version control, or general stability) the Special Folders detailed on the below page offer a simple way to do this, which requires no additional configuration, and they will be found by the Deep Search automatically.
https://www.visualmicro.com/page/Special-Folders-and-Portability.aspx

Well, the corrupted VCXPROJ was not the problem.  I created a new project in the same solution, copying some files from the original project, and referenced the same libraries and shared code.  And it still recompiles all the libraries every time - with the exception of one file in the FastLED library, and takes even longer...

I experimented with the Special Folders, and I simply cannot get it to list libraries in the special folders.  I gather that all you need to do is create the folders, paste in a library, and it should appear in the Add library list?  Not working for me, does not get listed.

I also tried a solution with all my own libs moved from the solution folder into the sketchbook libraries folder except for one that has mods, so is a shared project for now.  So the libs are now just added with the Add Library control, no shared project.  I had to turn on Deep Search with the gcc -E option for it to build- it took 27 minutes or twice the time of the previous solution's full recompilation that I was complaining about.  A second build with no code changes took 30 minutes, so is there no caching?  I am new to the deep search, it not being needed with my usual solution structure, but I understood that subsequent builds should be very fast.

I also tried the other (SCons) option.  It did not build, claiming not to be able to find Preferences.h, though it was added in the same way as all the other SDK libs, all of which it did find, and the gcc -E option found it OK.  Interestingly, Intellisense has a red squiggle under the #include.

So any help would be appreciated!

The Special folders feature worked as described, but required a PC reboot.  As far as I remember, restarting VS did not refresh the library list, but the PC reboot did.  Since then, I've experimented with it a little and it seems to have a lot of potential for better organizing a project.

I will email you logs of the things you requested, but I'd like to reiterate that I am still having the issue when I do not use either of the deep search options.

Thanks.

Simon,
Thanks for that.   

There seems to be a problem with my standard solution (no deep search required):  the project name is shown as "Sketch" (s/b "Aspects") and there are no references, and no option to build.   I attach screen shot.  The .vcxproj file is much shorter than it should be, which I suppose explains it.  The odd thing is that I compiled it this morning (the .obj folder has the results dated at 6:33AM), just before I loaded the new VM version.  After restarting VS, that's what I got.   However, the file change date of the vcxproj shows May 17, so I have no idea what is happening.

The SCons option took 24 minutes for the first pass, then 8 minutes for a rebuild.

The gcc -E option also took 24 minutes for the clean build, but 28 seconds for a rebuild.

So the deep search stuff is great, but doesn't help the issue I reported.

Well, that is the odd thing.  The file is actually called Aspects.vcxproj, and is referred to as that in the .sln file, but it contains the lines:

Quote:


Since the file change date is May 19th (I mistyped May 17), I must assume this was what was active when I recompiled this morning, before the VS upgrade, so it's a mystery to me why it all seemed to work just as before (with the project still listed as 'Aspects').  I can only assume I did something really stupid on May 19th that only took effect when I reloaded it today.

I am currently rebuilding the whole solution as it was, as the deep search time is killing me.  An no-changes rebuild takes 28 seconds, but adding a one-line function to a .cpp file took 8 minutes.  Adding all the libs as projects and referencing them is more work but is much quicker.

Yes, I did open it from the VS splash screen.