Well, more accurately, I broke the build because I introduced Rhino Mocks 3.5!

After working in a new Team Foundation Server (TFS) branch for a couple of weeks it was decided the work was significant enough to warrant its own automated build. As usual a clone of the main development branch’s TfsBuild.proj was taken and adapted for the new branch. 15 minutes later I get an email from TFS to say the build has failed.

The error listed in the Build.log was:

C:\Program Files\MSBuild\Microsoft\Windows Workflow Foundation\v3.0\Workflow.Targets(80,3): error : 'System.IO.FileNotFoundException' while invoking the validator 'System.Workflow.ComponentModel.Compiler.CompositeActivityValidator' on activity XYZ: System.IO.FileNotFoundException: Could not load file or assembly 'System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.
File name: 'System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'

A fairly ugly error, but it claims the build machine is having trouble finding the .Net Assembly System.Core Version 3.5.0.0. Not surprising really, as our main development is still using Visual Studio 2005, so the build machine has never had the .Net Framework 3.5 installed!

I reasoned that somebody with Visual Studio 2008 on their machine had added a reference to a .Net 3.5 assembly into one of our projects. Starting with the project that was falling over, I checked them all. No problems there.

Then I remembered one of the changes I had made was to upgrade from Rhino Mocks 3.1 to 3.5. After changing all the calls to CreateMock to StrictMock the upgrade was straightforward. All existing tests worked as before. Surely that wasn’t the problem? To double check I re-downloaded the Rhino Mocks 3.5 - For .Net 2.0 version and kick the build off again… same error!

Just to be doubly sure I used reflector to check which assemblies Rhino.Mocks.dll referenced… and there it was System.Core 3.5.0.0. I backed out my StrictMock changes and upgraded to Rhino Mocks 3.4 instead. Then the build machine was happy again.

I’m guessing this is deliberate as Rhino Mocks 3.5 uses features of the .Net Framework 3.5 (which is built on the version 2.0 of the CLR). However, I don’t have time to investigate at the moment. It didn’t help that the error was reported against a project that didn’t even reference Rhino Mocks! Just be aware, the Rhino Mocks 3.5 - For .Net 2.0 is not as backward compatible as you may like!