Looking to adress an issue with compiler flags, I looked at the commandline.  Oh my.  It is 48547 bytes long.

That makes it essentially unreadable, I'm kinda impressed things don't crash under the weight of such an absurdity.

It's got 248  -I directives.

4 things about that.
- it makes ordinary examination of the commandline a nightmare.  
- it makes adding your own additional include directories hard if you don't expand the edit-list-of-entires window.  At it's initial size of 2 entries-displayed, the poor little editor is choking on 50kb of text.
- the issue is made worse on all fronts by using relative path notation to navigate to absolute (in the sense You Absolutely know those locations from the root) locations.
- in my large project work, the msvcc comandlines are order of 300bytes, these 50kb ones to compile blink seem outlandish.

Might I suggest investigating compiler response files?

Might I suggest an envvar or two along the lines of $(SolutionDir)?  The same advantages that provides in general would work well here.  It would sure help out the poor little ist-of-dirs editor, if nothing else.

One could also use a symbolic-link and shortcut 95% of the commandline volume.  If it's in a response file, perhaps it would not be work the trouble.  However, it would sure help if response files are somehow unavailable to you..

In my case the common prefix for those -I includes is:
c:\Usr\Arduino\Sketches\blink\..\..\..\..\Users\pdp\AppData\
Local\Arduino15\packages\esp32\tools\esp32-arduino-libs\
idf-release_v5.1-632e0c2a\esp32\include\

No shock, it is to a point down into the esp32 core.   

Here is my puzzlement..

You folks have clearly got the chops.  The VisualMicro extension is an impressive piece of work.  You clearly know where the cores are, and it's gotta be you telling VS about all those -I's.  

So you know the relevant facts and are in a position code&sequence-wise to do something intelligent about it.

So, why is the compile command line 48kb?

Again, I am very impressed with VisualMicro.  I'm not trying to bust anyone's chops here.  I am just trying to set my expectations in the right zone...

If you want to force the -I paths to be relative, this can be achieved by adding a local board.txt to the project (vMicro > Add Code > Add Local board.txt), and adding the attached entries.

If you then restart Visual Studio and perform a build again the -I paths should be shorter.

Quote:

Arduino compatibility is one of the main features of Visual Micro, and we adhere to these standards to ensure code created with Visual Micro can be used by Arduino users in other IDE's.  We add additional features over and above this (Shared Projects, Serial/WiFi Debugging etc).

Quote:

The recipes which determine the command line used, are authored and maintained by the board package creator (in this case Espressif) so it is up to them to use the @file commands as they see fit.  Visual Micro simply merges and runs these recipes following the Arduino standards.

Espressif do reference a large number of internal IDF libraries in their recipes to deliver various features of their ever expanding range of MCUs.

The recipes can be overridden in a local board.txt file if you want to alter how the compilation runs for your specific builds.

Quote:

If you enable the vMicro > Compiler > Shared Cache for Cores option, this will ensure the core is compiled separately from your project.  When cleaning the project the Shared Core will remain in tact.  If you clean the solution, the cached core will be cleaned as well.  The core is also recompiled if the command line for the core compilation is changed to ensure it is up to date with the current settings.

Quote:

The "Visual Micro (No IDE)" option will still use all of the same recipes defined by Espressif's board package.  The No IDE option simply removes the detection of settings (Sketchbook/Library/Package locations) from other IDE's (Arduino/Energia etc).  
https://www.visualmicro.com/page/User-Guide.aspx?doc=First-steps.html