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


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.

Comments (13)
  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. @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. RichB 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.

  8. Trass3r says:

    Works like a charm in VS2015.3! Thanks a lot.

  9. Karel Vergauwe says:

    Is this registry settings still available in Visual Studio 2017. There is no “general” folder in the VisualStudio\15.0

  10. Manfred Roßkamp says:

    I tried this with visual studio 2017 without any success. Any Ideas?

    1. McCready says:

      I was also having this issue. I found that VS 2017 now uses a private registry hive, which means these settings don’t live in the registry anymore, but in a file, loaded by VS. I found instructions that worked for me in this post:

      I hope this helps,

  11. McCready says:

    Same here, I cannot get this to work with VS2017. This should always be on at normal verbosity.
    Where did all the reg keys move to in VS2017?


  12. pde14 says:

    In VS2017 go to “Tools…Options…Projects and Solutions…Build and Run” to set build verbosity.

    In my case I had a solution with 2 projects, an EXE and a DLL. Changing the projects from AnyCPU to x86 changed the output path from .\Debug to .\x86\Debug but the EXE was re-built every time because it still checked the DLL’s old output folder. Fixed by removing the DLL reference from the EXE references list and then adding it back in.

Comments are closed.

Skip to main content