Feb 23, 2012
5.948 Besuche

When Visual Studio keeps rebuilding Projects that have not changed

When Visual Studio keeps on rebuilding projects that did not change it can be a quite time-consuming pleasure. Many of you might have solutions of a similar or even greater size than mine (with currently 40+ projects) and hitting the build button twice (and waiting twice) one cannot help but wonder why the second build takes just as long as the first one.

After taking some time investigating the project settings of those unchanged projects, I came up with some tips on how to avoid/minimize the rebuild-effort.

There are some pitfalls to avoid which cause an unchanged project to rebuild. Most of them are not obvious, and making things even more difficult: VS seems to be of little help when you try to circle in the problem. Also, I used VS 2008, outdated though it may be, for the IDE was not my choice in here.

Pitfalls

  1. Copy local (Reference)

  2. The worst option seems to be if you copy files from within the same solution that other projects are using to their path via copy local. VS notices the frequent update and keeps on rebuilding. Use a Post-Build-Event instead to copy the files if really needed (see below).

  3. Bad Path

  4. If you are missing a .. when wanting to output all the files to the same directory or have any similar problem with your output path, this also can cause rebuilds.

  5. Post-Build-Events

  6. They have a nice option to only run “When the build updates the project output”. This typically makes a lot of sense, since most Post-Build-Events will do something with a (newly) changed file, like copy it somewhere else. If the file has not changed, only very few actions would make sense.

  7. Circular Reference

  8. Circular References are a bad thing and should be avoided in general (no possibility to build “from scratch”). Also, they most often are avoided by a decent design and since they mostly only cause problems: don’t use then.

  9. Specific Version (Reference)

  10. Typically, you want to avoid this, at least when you want to build care-free. If you have a lot of problems with versioning, you might want to keep this option set. In most cases, you will not have a problem with switching this option off even if you do need specific versions, since you typically know specifically which specific version you specified and everything should com out as expected.

  11. Dependencies

  12. Keep your dependencies in a sensible order. You should include necessary dependencies and avoid those that are not necessary among your own projects. If you don’t, this can mess up your build order, causing you to have to rebuild multiple times till you have a version that even compiles error-free. Also, include as few dependencies as possible. If C is dependent on B is dependent on A you should have exactly that dependence and not mark C to also be dependent on A. This is inferred automatically and makes later changes easier.

More Tips on hunting Problematic Projects

One easy thing is to force compiler warnings, e. g. by using

#warning Project was rebuilt!!

to notify you whenever a project rebuilds. This warning is only written to the build output when the project is actually compiled (or at least that sourcefile).

One more thing is to corner down the project that causes a rebuild. If you watch closely, it is often the case that when you build a specific project and its dependencies, the build is very fast, there is hardly any output, and no rebuild was done. The same projects though can be rebuilt if you build another project that is dependent on those. So hunt for a minimal subset of projects which to examine.

Lastly, I have noticed that when I choose “Build Solution” several projects are always rebuilt, though when I choose to build the main project (that is dependent directly or indirectly on every single other project) it does not rebuild anything the second run. Comparing the build output of the 2 runs with WinMerge I found no difference in project build order, only in the fact that the “Build Solution” rebuilds some projects.

Also note that the “Only build startup projects and dependencies on Run.” option you can find under Tools->Options->Projects and Solutions->Build and Run can speed up your debugging a lot (starting your projects e. g. with F5) with builds after code changes when debugging being often a lot faster.

Conclusion

Using all those ideas, you can speed up your build effort considerably, especially since I am strongly missing the “Rebuild Project” option that I grew accustomed to in VS6 (I think?). Especially the quick “does it still compile?” check once in a while to figure out how close to valid code the last few lines one wrote are will become again what it should be: quick and effortless.

3 Kommentare

  • Thanks for a good post, (it didn’t help directly, but triggered the thought that found the problem!)

    Tip: If you have any data files in a project, check if they are “Copy if newer” rather than “Copy Always”. The latter setting seems to cause VS 2012 to rebuild the project every time (where this was not the case in 2005, 2008, and 2010)

    A really useful diagnostic tip is to go to Tools > Options, Projects and Solutions, Build and Run options, and turn the MSBuild output verbosity up to “Diagnostic” temporarily. Then try a build and find the point where it builds each project (“Build Started: Project: XXXX”). Immediately before this line, MSBuild will usually tell you why it chose to rebuild that project.

  • Thanks for the tip!

    Projects settings still are a bit of a red flag to me.. 90% of the time, everything works fine with defaults, and if not, it is all the more complicated.

  • Thanks to the author and special thanks to Jason Williams whose comment actually helped =] Nice verbosity switch I overlooked a dozen times

Einen Kommentar schreiben