Visual Studio Builds Projects Every Time I Run

Question

I have a .NET solution in Visual Studio 2010 with a bunch of projects. Up until recently, when I would run the startup project from within the IDE, projects would only buil

Answer 1

In my case reason was not synchronized system time after I rebooted from Linux to Windows.

Answer 2

I landed here looking for a solution to my own situation and none of the answers provided a fix.

After investigation I discovered a situation where UWP projects are compiled every time if the Copy to Output Directory property value is set to Copy always or Copy if newer on xaml files. In the past this would help solve certain compile issues, however since the introduction of xbf these values on these files force Visual Studio to recompile every time, even when there are no changes to any source code.

I wrote a blog post about it: Preventing Visual Studio Recompiles in UWP

I hope this helps someone.

Answer 3

If Visual Studio is requiring a full build every time I would first be checking my settings (already mentioned) and then I would check the conditions VS uses to identify what needs to be built. I know VS checks timestamps on all input files when checking what needs to be built. I've seen cases where a linked generated file causes all downstream dependents to build every time, even though the content of the generated file was the same. Here's a link to MSDN incremental builds.

http://msdn.microsoft.com/en-us/library/ms171483.aspx

I'm not sure if there are other conditions VS uses to identify projects that need to be built.

Answer 4

I had a unique situation where some of my source files were from future. I needed to test some code with changing system time and modified the code in future date. Then, when I switched back to present those files caused the project to be rebuilt on every run. Solution is simple, create a new file and copy content of those modified files there.

Answer 5

The cause could be many things, so without having your solution + projects, we can only guess.

The typical way I handle this problem is by narrowing it down with a binary search. That is,

1. I build everything.
2. Next I find something in the middle of the build order and build that project. If something that that project depends on is the culprit, you'll experience the issue. If something that it doesn't depend on has the problem you won't (i.e. it will say all projects skipped).
3. Now you repeat this process until you narrow it down to (hopefully) the project that has started causing the problem.

This (of course) only works if there is a single project that introduced the new problem (which is likely).

One of the culprits in my specific situation was having an x64 project reference an x86 project that wasn't selected to be built in the x64 configuration.

Answer 6

I'll share the best answer i've found here on stackoverflow and combined with matt smith's accepted answer here, i´ve reached the root cause of my problem:

By configuring Visual Studio to log the build output in a "Diagnostic" manner, as explained in this answer: https://stackoverflow.com/a/29649259/2740778, the very first line on the output explains why MSBuild determines to rebuild a project.

So, if you have, let's say 3 projects into a solution:

• Library0
• Library1
• Application

referenced this way: Application references Library1 and this one references Library0. By selecting "Build" for the Application project, the first time it should build all the referenced projects in order. But from now on, if no changes where made, pressing "Build" should not build anything, because MSBuild detects that changes where not made. A similar log output should be displayed:

========== Build: 0 succeeded, 0 failed, 3 up-to-date, 0 skipped ==========

But now, if changes where made, if you have the MSBuild log output level on "Diagnostic", the first line in the output window will display the reason of why does Visual Studio decides to build a project, like here:

Project 'Library0' is not up to date. Input file 'c:\Library0\Class1.cs' is modified after output file 'c:\Library0\bin\Debug\Library0.pdb'.