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 build if changes had been made to the code in either the startup project or one of the dependency projects.

About two weeks ago I noticed that every time I run the startup project, Visual Studio builds all projects, which takes about seven minutes. Needless to say this is taking a large amount of time out of my day, and I've tried my best to look online for solutions, but have yet to find any solutions that address my specific problem.

A few additional pieces of information - the same problem began happening to everyone else on my team around the same time that I began experiencing this issue.

We are also using a source code repository. Since we didn't change any settings in Visual Studio, my suspicion is that someone inadvertently changed something in the source code for some project that now requires all projects to build every time.

Any suggestions would be greatly appreciated.

Are any of your projects set to 'Register for COM Interop'? That was the issue for me. — C-Pound Guru, Jun 09 '14 at 13:06
How are your projects referenced? Do you have any pre or post build actions or custom build targets? Are your projects strongly named? — Trevor Tubbs, Jun 09 '14 at 13:19
Does the build output give any clues as to which earliest dependency of your projects is consistently out-of-date? Have you reviewed the commit history for modifications to project files? — Jason Kleban, Jun 09 '14 at 13:28
You already know what you should look at. You can't get a reliable answer until you post the msbuild trace. — Hans Passant, Jun 09 '14 at 13:44
Check if your system clock is set alright and if there is any other program like DropBox or any sync service changing few files regularly in source folders. — Akash Kava, Jun 09 '14 at 13:45
We are using ClearCase, unfortunately, and have for sometime, however, as I mentioned in my original post, this issue is recent, and since it is affecting all team members, I suspect that something in the source code for some project changed, resulting in this problem. — Chris, Jun 09 '14 at 14:11

score 18 · Accepted Answer · answered Jun 09 '14 at 13:27

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,

I build everything.
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).
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.

I'm going to follow these steps and will circle back to you shortly with the results. Thanks. — Chris, Jun 09 '14 at 14:18
FYI - these steps led me to isolating the root cause. Someone on my team had inadvertently created a circular reference by referencing the binary version of a project in the solution, so the binary version was always slightly out of date from the newly compiled version. Removing the reference solved this problem, as the reference wasn't even needed to begin with. Thanks for your help! — Chris, Jun 09 '14 at 16:51

score 12 · Answer 2 · edited May 23 '17 at 12:10

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'.

Hanno · Answer 3 · 2014-06-05T14:53:54.577

5

Go to Tools -> Options -> Project and Solutions -> Build and Run. Look at the options there. 'Only build startup projects and dependencies on Run' should be checked.

Additionally, you can set the build output (in the same options screen) to Detailed or Diagnostic to see if you can find any clues why the projects are built every time.

edited Jun 05 '14 at 14:53

answered Jun 05 '14 at 14:48

Hanno

1,017
11
18

Thanks for your response. We've tried your first suggestion in the past, as that seems to be a common solution online, however that didn't help, and, in my opinion, we all shouldn't have to modify the build settings in Visual Studio if we never changed them to begin with. Does that make sense? With regards to your second suggestion, I will try that out. I've changed it previously to Diagnostic and saw nothing in the build output that was helpful, but I will try changing it to Detailed. – Chris Jun 05 '14 at 14:59
your suggestion did not resolve my issue, unfortunately. – Chris Jun 05 '14 at 18:26

Deetz · Answer 4 · 2017-03-09T21:47:48.927

In my experience with this issue, it was only some of the projects that rebuilt, and the rebuilds failed several times before finally succeeding. It was apparently caused by the \rootprojectdir\.vs\%projectname%\v14\.suo file being corrupted. This also caused the same projects to require rebuilding, and the same windows to be opened every single time I opened VS. Deleting the .suo file (while VS was closed) and reopening VS fixed it :)

score 2 · Answer 5 · answered Jul 01 '16 at 20:55

2

Tools -> Options -> Project and Solutions -> Build and Run

Set your output verbosity to "Diagnostic". After doing another build, examine the output window. At the beginning of each project build, the build system will tell you which dependency is causing the project to be built.

(In my case, it was an .ico file that accidentally got set to Build Action: Resource and Copy To Output: Copy if newer. Very hard to find.)

answered Jul 01 '16 at 20:55

HiredMind

1,827
17
27

do you know if it is any disadvantage keeping, "Diagnostic" setting on always. is this causing build to be slower? – Emil Aug 30 '17 at 10:25
It probably is a bit slower, but the difference is so small it has never been noticeable. Like on a solution with ~50 projects, perhaps a second or two. – HiredMind Aug 30 '17 at 16:36
It would be interesting to create a VS addin makes this a lot simpler. Boy, I really miss CodeWarrior. – ATL_DEV Nov 29 '18 at 15:52

score 2 · Answer 6 · answered Nov 10 '18 at 08:30

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.

score 2 · Answer 7 · answered Apr 11 '19 at 14:49

TargetFramework in .csproj vs. supportedRuntime-sku in app.config

Just found another reason for rebuilds (at least with the new sdk-style project files, didn't try for the "old style" projects): if the TargetFramework element in the .csproj file does not match the sku-attribute of the supportedRuntime-entry in the app.config, visual studio will also rebuild the project every single time.

For example, targeting 4.6.2 in the .csproj

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net462</TargetFramework>
  </PropertyGroup>
</Project>

vs. 4.6.1 specified in app.config

<configuration>
    <startup> 
        <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1"/>
    </startup>
</configuration>

will trigger a rebuild.

score 2 · Answer 8 · answered Feb 22 '21 at 09:15

For SDK style projects, there's now also "Projects and Solutions" -> "SDK-Style Projects" -> "Logging Level". When debugging incremental builds, set that to "Verbose".

In my case there was a .dll.config expected due to AutoGenerateBindingRedirects, but it wasn't found. This caused incremental build to fail. In the end it was a bug in Visual Studio and was resolved by removing some project-related cache files.

score 1 · Answer 9 · answered Jun 09 '14 at 13:09

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.

score 0 · Answer 10 · answered Mar 21 '19 at 07:13

There can be many reasons for MSBuild to detect a need to rebuild the project.

In my case, I have a bunch of Pre-build events that generate code from XSD files. These causes the project to be rebuilt every time. And then other projects depending on this one will be rebuilt as well.

score 0 · Answer 11 · answered Jan 04 '20 at 23:23

0

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

answered Jan 04 '20 at 23:23

Dmytro

1,290
17
21

score 0 · Answer 12 · answered Jan 18 '20 at 03:51

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.

score 0 · Answer 13 · answered May 19 '20 at 17:58

My Configurations tag in a low level project (i.e. one many others depended on) had 3 entries:

 <Configurations>Debug;Release;Debug31</Configurations>

I had been experimenting with a new configuration (Debug31) and forgot about it. Removing the Debug31 configuration from the project file solved the issue. Note that the solution that contained all my projects did NOT have a Debug31 configuration. This appears to have caused this project to always be out of date, even though I was only building 'Debug' or 'Release'. Why I am not sure.

score 0 · Answer 14 · answered Oct 20 '21 at 14:30

In case you do not want to search for missing files each time, what about simple script ?

Put it to vcxproj(.filters) folder and run with strange project name as parameter like
cscript printMissingVSprojFiles.js strange.vcxproj

And you will get list of all missing include files (in ItemGroup / ClInclude & ClCompile).

var fso = new ActiveXObject("Scripting.FileSystemObject");  
var arg = WScript.arguments(0);
var xml = readFile(arg), xml2;
xml = xml.documentElement.firstChild;
do {
    while (xml && xml.nodeName != "ItemGroup") xml = xml.nextSibling;
    if (!xml) break;
    xml2 = xml.firstChild;
    while (xml2 && (xml2.nodeName == "ClInclude" || xml2.nodeName == "ClCompile"))
    {
        var path = xml2.attributes.getNamedItem("Include").nodeValue;
        if (!fso.FileExists(path))
            WScript.Echo(path);
        xml2 = xml2.nextSibling;
    }
    xml = xml.nextSibling;
} while (xml);

function readFile(filename)
{
    var xml = new ActiveXObject("Msxml2.DOMDocument.6.0");  
    xml.async = false;
    xml.load(filename);
    return xml;
}

function writeFile(filename, content)
{
    var TextStream = fso.CreateTextFile(filename);
    TextStream.Write(content);
    TextStream.Close()
}

score -1 · Answer 15 · answered Jun 24 '19 at 09:28

-1

The following worked for me. Go to Properties->Custom_Build_Step, and delete anything in "Description" field.

answered Jun 24 '19 at 09:28

YScharf

1,638
15
20

Visual Studio Builds Projects Every Time I Run

15 Answers15

TargetFramework in .csproj vs. supportedRuntime-sku in app.config

Linked