Mixing TFS 2008 and VS 2010

At work, we’re in the early phases of migrating our TFS 2008 setup to TFS 2010. However, since some teams have already started work on the new hotness that is VS 2010 and .NET 4, there was a need for us to get their automated builds up and running immediately. We “requisitioned” a desktop that was already running builds for another semi-defunct project using CruiseControl.NET, and installed Team Build on it.

It took a few tweaks to get the code compiling, but something was wrong with the testing phase – the tests would run, but the test runner would then report a failure, resulting in a yellow warning lights rather than nice green success lights. The error message was:

MSBUILD : warning MSB6003: The specified task executable "MSTest.exe" could not be run. The system cannot find the file specified [D:\Source\CommonPlatform\Common Platform Development CI Build\BuildType\TFSBuild.proj]

So the tests all passed, but then Team Build couldn’t find the testrunner that it had just used! We tracked down another user with the same complaint on StackOverflow, but they were shouting in the dark, with no response to their question.

After much head-scratching alternated with banging our heads against the wall and wondering why Microsoft products are sometimes to great and sometimes so plain awful (often in the space of just five minutes), we eventually found the solution to our problem tucked away in forum on MSDN. The TeamBuild targets file which imports the TestToolsTask has an invalid path reference:

<UsingTask TaskName="TestToolsTask" AssemblyFile="$(MSTestRefPath)\Microsoft.VisualStudio.QualityTools.MSBuildTasks.dll" 
Condition="'$(ProjectFileVersion)' == '2'" />

since MSTestRefPath doesn’t appear to be defined in VS 2010. By changing it to the correct path, the test runner can be found again, and the error disappeared.

Quite why Microsoft implemented it so that the tests would run but then fail afterwards I don’t know, but at least our builds are all happy, and the developers are happy. Hopefully we can now get back to migrating TFS 2008 to 2010, and we can see the back of this problem.