Share via

How to investigate Rebuilding in Visual Studio when nothing has changed

  • Article

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

  • Anonymous
    August 06, 2014
    Hi, it appears to be no key such as U2DCheckVerbosity in VS 2012. Any ideas? Thank you.

  • Anonymous
    August 07, 2014
    Would this be any different than going to Tools/Options/Project and Solutions/Build and Run and setting the verbosity of MSBuild to Diagnostic?

  • Anonymous
    August 07, 2014
    @Ali - Most of the times these kinds of keys don't exist by default. You can right click and create a new one.

  • Anonymous
    August 07, 2014
    @Christiaan thank you, I will do that.

  • Anonymous
    May 13, 2015
    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

  • Anonymous
    December 29, 2015
    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

  • Anonymous
    December 30, 2015
    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.

  • Anonymous
    November 17, 2016
    Works like a charm in VS2015.3! Thanks a lot.

  • Anonymous
    May 05, 2017
    Is this registry settings still available in Visual Studio 2017. There is no "general" folder in the VisualStudio\15.0

  • Anonymous
    July 17, 2017
    I tried this with visual studio 2017 without any success. Any Ideas?

    • Anonymous
      December 15, 2017
      Hello,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:https://developercommunity.visualstudio.com/content/problem/161997/full-build-every-time-with-155.htmlI hope this helps,

  • Anonymous
    December 08, 2017
    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?Thanks,

  • Anonymous
    November 16, 2018
    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.