There are multiple times when, for reasons unknown, a project rebuilds when the developer's expectation is that it should be considered 'up-to-date'. To diagnose why VS Project System disagrees with our expectation, the recommendation is to switch to diagnostic logging, build it, find the log file, and then pour over the (as promised) extensive verbose output.
In older versions of Visual Studio there was an easy 'tweak' to adjust the verbosity of ONLY the 'up-to-date checker' via the registry, which puts only those desired diagnostics in the build pane output window (via Krill Osenkov):
With the private registry hive in modern Visual Studio versions (VS2017+) toggling this 'Tweak' becomes very tedious (via this developer community discussion):
Close VS 2017/2019 and wait 20-30 seconds for it to release its private registry hive.
Run regedit.exe
Select HKEY_LOCAL_MACHINE File --> Load Hive...
Go to folder %LOCALAPPDATA%\Microsoft\VisualStudio
Select the 15.0* folder that does not end with Exp (16.0 for VS2019)
Select the privateregistry.bin file in that folder.
For example, C:\Users\MyUserName\AppData\Local\Microsoft\VisualStudio\15.0_4eff8961\privateregistry.bin
For Load Hive's Key Name just make up a name like VSTweak
The hive should now appear as HKEY_LOCAL_MACHINE\VSTweak.
Edit (or add) the U2DCheckVerbosity dword (32-bit) value to 1 (or 0 to disable) under:
Once that output is easily accessible via the build output level, it is generally easy to determine why... Several internet resources exist that discuss this issue, along with the output from this 'tweak' can help you further diagnose the issue, like this one and any of the other links I made from here.
Would it be possible/easy to add this to Tweaks, or give a hint as to how an extension may be able to accomplish this that could guide a pull request? I had once written an Add-In but other than tuning in for some 'Writing Visual Studio Extensions with Mads' have not explored writing my own.
There are multiple times when, for reasons unknown, a project rebuilds when the developer's expectation is that it should be considered 'up-to-date'. To diagnose why VS Project System disagrees with our expectation, the recommendation is to switch to diagnostic logging, build it, find the log file, and then pour over the (as promised) extensive verbose output.
In older versions of Visual Studio there was an easy 'tweak' to adjust the verbosity of ONLY the 'up-to-date checker' via the registry, which puts only those desired diagnostics in the build pane output window (via Krill Osenkov):
With the private registry hive in modern Visual Studio versions (VS2017+) toggling this 'Tweak' becomes very tedious (via this developer community discussion):
Once that output is easily accessible via the build output level, it is generally easy to determine why... Several internet resources exist that discuss this issue, along with the output from this 'tweak' can help you further diagnose the issue, like this one and any of the other links I made from here.
To play by the rules for requests for this extension, the most relevant developer community issue is There is no easy way to tell why a project rebuilds every time (is never considered up-to-date) but that is closed as 'lower priority', is not tagged as a suggestion, nor can it accept votes due to its status.
Would it be possible/easy to add this to Tweaks, or give a hint as to how an extension may be able to accomplish this that could guide a pull request? I had once written an Add-In but other than tuning in for some 'Writing Visual Studio Extensions with Mads' have not explored writing my own.