Wrestling with MSBUILD – the bane of /t:rebuild

The continuous build server at work does its magic with the help of the MSBuild.exe command. Of course, since we are checking integrity, we want to force a full rebuild every time.

In other words, I want to completed delete all previously built assemblies (aka dlls) and build them from scratch again. A seemingly obvious choice would be to use the /t: REBUILD flag to do this, since that is what is does. Doesn’t it?

I’m not rebuilding a project, but an entire solution.

Expected behaviour:
Rebuild solution = (run clean x N projects) + (run build x N projects)

• Clean for Project A
• Clean for Project B
• Clean for Project C
• Build for Project A
• Build for Project B
• Build for Project C

Actual behaviour:

Rebuild solution = (run clean + run build) x N projects

• Clean for Project A
• Build for Project A
• Clean for Project B
• Build for Project B
• Clean for Project C
• Build for Project C

The flaw is that the projects further down the list may result in the cleaning of dlls which were built earlier on the list.  Depending on the project specifics, these may or may not be included in the output.  Plus, there is the possibility of the same assembly being built more than one, which can result in conflicts in versions.  (i.e. Refers to dll v1.0.312 directly AND to dll v1.0.313 indirectly)

So, how did I find it?

I monitored the bin folder and observed some dependency dlls appearing, and then disappearing from the folder while the build was underway.

Strangely enough, if I ran a Solution Rebuild command from within Visual Studio, the problem did not occur. Thank you Microsoft for that wonderful INCONSISTENCY.

Final solution:
Instead of calling /t: REBUILD, I am doubling up on the MSBuild calls. I’m calling /t: CLEAN first, before calling /t: BUILD.