MSBuild has grown to quite a robust level since its introduction on 2003 and its inclusion in .NET Framework 2.0 in 2005.
While its core engine and targets are rock-solid consistent, sometimes there are cases where the later additions introduced in .NET 3.5 and 4.0 just don’t keep up with same level of stability.
Today I had one of these cases. It came from WPF’s Microsoft.WinFX.targets:
In this case, project ‘foo’ has a dependency on project ‘bar’, which has a dependency on a third project. So far nothing special. The weird stuff started to happen when “Machine A” was able to both Build and Rebuild successfully without an explicit reference to ‘bar’. “Machine B”, with the exact same code base failed. Then, on another attempt to Rebuild on “Machine A” this time via the command line: ‘msbuild foo.csproj /t:Rebuild’ it broke the build chain and started failing too.
On the first attempt, removing the WPFToolkit reference and re-adding it again seemed to the make the compiler happy. Project was compiled without errors. However, when executed the command line build above again failed the build. Finally, we’ve added to the ‘foo’ project an explicit reference to ‘bar’ – success.
The strange bit was that at some point both machines built the project successfully from a fresh start, except that “Machine A” did it without having to add this reference!
The only question remains – why didn’t the build fail consistently without the explicit reference in the first place? both machines had the same setup, with no previous caching of the missing reference. Since the failure reason was ‘Unknown build error’ and there are some similar cases of those on connect.microsoft.com, lead me to believe this is indeed a bug in the MarkupCompilePass1 task.