If one project can't build, Visual Studio, by default, keeps right on trying to build all the other projects that depend on that project, and therefore gets stupid errors because those other projects are now building against a stale version of the binary.
How can I change this behavior, and get it to stop on failure?
For example, suppose I have a library project called MyApp.Core, and an executable project called MyApp. MyApp calls a method in MyApp.Core. Suppose I add a new parameter to that method and then try to build, but I've inadvertently introduced an unrelated compiler error in MyApp.Core. When I build, Visual Studio will:
- Try to build MyApp.Core, and fail because of the compiler error. The MyApp.Core.dll on disk is left unchanged because the build failed.
- Go on to try to build MyApp against that older version of MyApp.Core.dll, and report compiler errors because it's passing more parameters than the method in the old DLL expects.
- Report the second batch of errors at the top of the Errors window, thus making it very difficult to find the actual problem.
Make has had this problem solved since 1977: when it realizes that it can't build, it stops building. Every other build system and IDE that I've used is also clever enough to stop on a lost cause. But Visual Studio hasn't quite caught up to the technological sophistication of 1977.
The book "Visual Studio Hacks", in its section on macros, has a workaround: you can write a macro that fires when a project is done building; if the project's build status was "failed", the macro can issue a Cancel Build command. I regularly install this hack on every computer I use that has Visual Studio. However, at home I use Visual C# Express, which doesn't support macros.
Is there any way to get Visual Studio 2010 (including the Express editions) to stop building on a build failure?
As much as I like MSBuild, there isn't a built-in way to do this when using the solution file to build (as you've already discovered). With Resharper's analysis enabled I find that compiler errors are very rare for me these days, so I rarely have the problem of overwhelming error messages.
At my previous shop, someone routinely gacked-up the build so that one of the root projects in a solution of over 60 projects and because of that, many people took to running projects individually from the command line similar to running individual Make files.
If you really wanted to handle this problem in a different way than the macro you mentioned, you could construct an external msbuild file that executes the projects individually and checks for errors in-between runs. You'll have to keep the build ordering correct, and you'll need to run it from the command line and/or add a shortcut to the Tools menu option.
Here's an example:
Replace the projects with your projects, and the group will need to be mimicked for the Clean target.
I wish there was a better solution and I don't know why the MSBuild team won't add this feature into the product. Like you said, Make figured it out decades ago. FWIW, I don't know how well this works with complicated build dependencies and build parallelism.
My problems with MSBuild center around the ResolveAssemblyReferences, and ResolveComReferences Tasks which are the slowest part of a build in a big solution with a large/complicated project dependency tree (large being relative ~30 projects at a minimum).
I hope this helps.