I just installed the update of the ESP8266 board manager which is version 3.1.0. I updated everything: VS Studio 2022, VisualMicro, the Arduino IDE 2.0.3, all libs and all board managers. Reboot/Rescan Toolchain etc is mandatory, of course.
I created an empty arduino project with empty Setup/Loop function in visual studio, set target to "Generic ESP8266 module".
Since then, compiling always failed with the following messages:
"Compiling 'Sketch1' for 'Generic ESP8266 Module                                                                                                    (esp8266_generic)'
   *** File preferences.txt not found on Windows
Error running platform build action hooks.prebuild

   *** preferences.txt file missing from well known locations
0 Protypes Discovered"

Surprisingly, the Arduino IDE 2.0.3 does not have this issue, compiling runs well there. Must be an issue of visual micro.
Whats ongoing here?
Returning to the most recent board manager 3.0.2 works.
Any suggestions? The board manager update is just 16 hours old, so I might be the first unlucky one failing here.

We found a way to feed the correct path into the python script of this tool chain. That will then work with same configuration as the arduino ide.

There should be an update available over the oming week. Although this package works outside of the published arduino spec. what it is doing is good.

More Info

Using the Visual Micro project level (F4) defines and compiler flags provides more flexibility than that provided by the global.h of the esp8266 package. This is because visual micro allows us to specify the defines and switches for each configuration (debug, release, foo, baa etc.) and/or global. 

Secondly, with visual micro settings, there would be a cache of the core for each set of defines and switches, as opposed to the cache being rebuilt every time the esp8266 .ino.globals.h is changed. 

That said the ino.globals.h offers some very advanced usage on top of defines and switches.

Both systems of course work side by side but it might be an idea to avoid the ino.globals.h when possible.