Could you attach the complete build output as a text file with the below settings enabled:

• vMicro > Compiler > Verbose
• vMicro > Compiler > Show Build Properties

It sounds like the tools haven't been fully removed from the previous 3.x version, but the logs will help us to guide you through this.

Thanks for the log and it doesn't appear there is any conflicting tools or core components in use there.

I assume the #include "driver/pcnt.h" is present in the INO file?

When you say you had "Promoted" multiple H files to the project folder, had you referenced them from the core directly, or had you cloned them into the project folder itself?

Did the project previously work with 2.0.17, or are you unsure which version it was before upgrading to 3.x?

Thanks for the detail.

The ESP32 board package changes between its versions quite a lot even within 2.x, and the 3.x is a larger restructure of it all (along with shifting IDF versions beneath).

Cleanup
As you have copied files into the project which are from the 3.x package I would suggest removing those from the project via Solution Explorer to begin with as they will be adding to the confusion for both intellisense and compilation.  Once they are removed and the board package is the same version as before then this should work.

Also disable the Serial Debugger in vMicro, just in case this is causing any confusion (it shouldn't, but to be safe...).

If it seems like some components aren't being uninstalled correctly, close VS, and delete the %LOCALAPPDATA%\Arduino15\packages\esp32 folder entirely, then open VS and reinstall the board package.

Intellisense
The fact the compiler did not find the files is an issue of its own, and should be resolvable without the need to clone core files into the project (allowing simpler upgrades when needed).

IDF Versions
The 2.0.17 board package is built upon IDF v4.6, and each board package version contains the IDF components it was built with. It cannot be used like a library or component, it is what the board package is built with so it all fits together as one unit.

Arduino Core Version	ESP-IDF Base Version	Notes
v2.0.0	ESP-IDF v4.4	First stable 2.x release
v2.0.1 – v2.0.6	ESP-IDF v4.4	Bugfix and incremental updates
v2.0.7 – v2.0.10	ESP-IDF v4.4.2	Stability improvements
v2.0.11 – v2.0.14	ESP-IDF v4.4.3	Widely used in production
v2.0.15 – v2.0.16	ESP-IDF v4.4.5	Late-stage bugfixes
v2.0.17	ESP-IDF v4.4.6	Final 2.x release; most mature v4.4.x base

Arduino Core Version	ESP-IDF Base Version	Notes
v3.0.0	ESP-IDF v5.0	Major changes: drivers, components, APIs
v3.0.1 – v3.0.7	ESP-IDF v5.0.x	Gradual bugfixes and compatibility work
v3.1.0	ESP-IDF v5.1	Major feature update
v3.2.0	ESP-IDF v5.1.2	Most stable 5.1-based release
v3.3.0 (upcoming)	ESP-IDF v5.2.x (likely)	More IDF 5.2 support (Matter, BLE Mesh, etc.)

Future Final Solution
This is the ideal scenario (once working again) to recreate the project and its' board package as a Portable Solution, so the Solution, Project, Board Package and all libraries live in an isolated folder, separated from your normal board package and library installs:
Documentation: https://www.visualmicro.com/page/New-Arduino-Portable-Solution.aspx
Video Guide: https://www.youtube.com/watch?v=PEkaumrbFAc

This can be done in-place without the wizard by closing the solution and creating a few folders as shown here, then re-installing the boards/libraries needed:
Documentation: https://www.visualmicro.com/page/How-to-Encapsulate-a-Board-Package-with-a-Solut...

Thanks for the update, and the fact that both IDEs fail to install suggests either a networking issue or a corrupted ZIP.

Can you delete the %LOCALAPPDATA%\ Arduino15\ staging\ staging \packages \riscv32-esp-elf-gcc8_4_0_esp-2021r1-win32.zip, and then try installing again from either IDE?

Is 2.0.17 definitely the right package, or could it have been an older 2.0.11 version for example?

Would it be possible to share the full project in a ZIP file, or email it to us to review (exclude the ".vs" folder so save space)?

It's midnight here; I'm drawing stumps but play with this more tomorrow.
Roman

Thanks, Simon.
I did all that and it built just fine, at last. Seems like, had I left in that one header (driver/pcnt.h) it probably would have worked, although I missed the bit about the Intellisense upgrade.
My current interest in this file was, in fact, spawned by a desire to upgrade it to the newer register approach. But first I am going to try to "freeze" what I have in a portable version.
It appears to me that, rather than modifying the structures of the existing solution (notwithstanding that your instructions seem quite clear), I will first try to create a brand new portable project using the wizard, copy across the original source files, and hit "go". Might be simpler...

Yet again, thanks heaps for your help.
Roman

So then I thought to try your method of modifying the structure of a working version and tried to make a copy of same, using a similar process but starting with a "normal" new VMicro project, copy in the source files to the solution folder, open them in VS, etc. So now I thought I had two identical environments, the only difference being a "_V2" suffix to the project name. Again, "No issues found" but refuses to build with completely different errors reminiscent of my earlier problems. I have attached that log.

To confirm - All this time my original solution, thanks to your help, sits in its folder and continues to build reliably. I don't want to mess with this in any way until I have a handle on a satisfactory cloning process. But I eventually want to upgrade my toolchains, etc, so I can move forward.

I realise that I can "clone" these solutions by using a git "branch" thing, but that still won't let me put a "known good" and complete portable package aside while carrying on.

There's GOT to be a way!
Roman

Thanks for the detail and glad there is some progress with the initial project at least.

In the "Dump2" log it seems not all files are registered in the project itself as it doesnt show it building the ESP32_Quad_Encoder.cpp or ESP32_Touch_Tacho.cpp.  If you click vMicro > Ensure All Files In Project, this should ensure they are visible in Solution Explorer and built as well.

I'll test the same setup for the portable solution on monday, however one element which can occur is the internal compiler paths get longer than windows allows by default.

If you enable "Long Paths" in Windows this often resolves the issue, though without testing I can't confirm this is the case currently for this setup:
https://www.visualmicro.com/page/Enabling-Long-Paths.aspx

I also had another go and building my non-portable clone copy. I noticed that debug was "ON" in both cases, so I disabled it and tried again - same result. I scanned the resulting output and indeed it does look like the two .cpp files simply failed to build. I can confirm that "Include all files" has indeed been ON the whole time.
I can also confirm that I CLEAN and RESCAN prior to every build.