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.
The problem Sometimes, Visual Studio will always rebuild projects, even though they have recently been built and there are no changes. If you build , and then run the project will build. If you haven't disabled the “projects out of date”-dialog, it will pop up and ask you to rebuild.
You can hit Ctrl + Break on the keyboard to cancel/stop a build that is currently in progress.
Clean Solution - deletes all compiled files (all dll's and exe's ). Build Solution - compiles code files (dll and exe) that have changed. Rebuild Solution - Deletes all compiled files and Compiles them again regardless of whether or not the code has changed.
For a multi-project solution, "rebuild solution" does a "clean" followed by a "build" for each project (possibly in parallel). Whereas a "clean solution" followed by a "build solution" first cleans all projects (possibly in parallel) and then builds all projects (possibly in parallel).
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,
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'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:
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'.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With