How to investigate Rebuilding in Visual Studio when nothing has changed


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

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\General]
"U2DCheckVerbosity"=dword:00000001

Then after building, rebuilding or F5-ing pay attention to the Output window (Build pane):

image

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.


Comments (7)

  1. Ali Servet Donmez says:

    Hi, it appears to be no key such as `U2DCheckVerbosity` in VS 2012. Any ideas? Thank you.

  2. J.P. Hamilton says:

    Would this be any different than going to Tools/Options/Project and Solutions/Build and Run and setting the verbosity of MSBuild to Diagnostic?

  3. Christiaan Rakowski says:

    @Ali – Most of the times these kinds of keys don't exist by default. You can right click and create a new one.

  4. Ali Servet Donmez says:

    @Christiaan thank you, I will do that.

  5. Anonymous says:

    I've got a lot to read through:

    λ ls -l msbuild1.log

    -rw-r–r–    1 user  Administ 267920508 May 14 11:00 msbuild1.log

  6. Wayne J says:

    I tried this in VS2015U1 and don't see any changes in the logging.  Is this different in 2015U1?

    Key Name:          HKEY_CURRENT_USERSoftwareMicrosoftVisualStudio14.0General

    Value 41

     Name:            U2DCheckVerbosity

     Type:            REG_DWORD

     Data:            0x1

  7. Kirill Osenkov says:

    Wayne – you might have fast up-to-date check disabled. It's hard to investigate but double check that the MSBuild property DisableFastUpToDateCheck is not set in your project. Other than that unfortunately I have no idea what could be going wrong.