In some managed projects there’s this unfortunate behavior: you press F5 in VS, run your app, stop, then press F5 again and it says “Building…”. Why is it building when nothing has changed? Or you change something in one project and multiple seemingly independent projects are being rebuilt as a result. This slows you down, wastes precious time and is simply annoying.
Unnecessary rebuilding can result from one of two things: either MSBuild itself decides that a project needs rebuilding, or the Visual Studio fast-up-to-date check reports a project is out-of-date. When MSBuild itself rebuilds from the command line unnecessarily (incremental build doesn’t work), the best way to investigate that is to call msbuild /v:diag /fl1 /noconlog (verbosity diagnostic, which is most verbose, output full log to file called msbuild1.log and don’t spew anything on the console). Diagnostic log will then contain detailed explanation of why every project was chosed to be rebuilt.
However what few people know is that there is a way to investigate the Visual Studio fast up-to-date checker. Basically this is a feature in Visual Studio where before even calling MSBuild to build it quickly checks if any of a project’s input files are modified later than any of the project’s outputs. For instance, if you have a .cs file that goes into the project and it’s modified date is newer than the .dll built by this project, fast up-to-date check calls MSBuild. If not, it reports that the project is up-to-date and MSBuild isn’t even called in the first place. If or when MSBuild gets called, it then can also decide based on its more precise heuristics whether it should just reuse previous outputs or a full rebuild is needed.
So, to get some information about VS fast up-to-date checker, set this registry key:
Windows Registry Editor Version 5.00
Then after building, rebuilding or F5-ing pay attention to the Output window (Build pane):
VS will display diagnostic information about why it chose to rebuild a given project.
A pretty common reason is that Copy always is set on some file. Change it to Copy if newer to solve the problem.
Pay attention to your builds and make sure there’s no overbuilding, double-writes and other unpleasant phenomena that slow you and your team down.