Building VS2008 projects with TFS Build 2010
TFS Build 2010 uses MSBuild 4.0 to compile the solutions/projects and MSBuild 4.0 is capable of handling the backward compatibility with .NET 3.5 projects. So you will be able to build VS2008 projects in TFS Build without having to upgrade them to 2010 provided required tools are installed on the build machine.
MSBuild 4.0 comes in 32bit and 64bit versions and TFS Build provides a way to be able to choose one over the other. In the build process, TFS Build exposes a property called “MSBuild Platform” that can have 3 values – “Auto”, “x86” and “x64”. The default is “Auto” which uses the 64bit version of MSBuild on 64 bit machines and 32 bit version on 32 bit build machines.
There are some additional requirements/workarounds needed for some project types to work with MSBuild 4.0.
VC++ 2008 projects:
If you are building VC++ 2008 projects, you will need to install VS2008 or the Windows SDK (v6.1) to lay down vcbuild.exe and its dependencies. If your build machine is 64 bit, you will also need to include the path to vcbuild.exe in the PATH environment variable and restart the TFSBuildServiceHost service.
If the build machine is 64 bit but you are specifically targeting “MSBuild Platform = x86”, you might see errors similar to:
“C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets (1682): Use of Tracker.exe is required to correctly incrementally generate resources in some circumstances, such as when building on a 64-bit OS using 32-bit MSBuild. A build that falls into this category was attempted, but Tracker.exe could not be found. Please verify that it exists in the appropriate .NET Framework directory or turn off incremental building of GenerateResource via setting the "TrackFileAccess" property to "false".”
To workaround this install VS2010 (to install the Windows SDK (v7.0A)) to lay down Tracker.exe and its dependencies.
.NET Compact Framework projects:
Update msbuild.exe.config file on the build machine as suggested in Jim Lamb’s post
Test projects:
If your build machine is 64 bit, you might see errors similar to “ResGen: Could not load referenced assembly "C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.QualityTools.UnitTestFramework\v4.0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll". Caught a BadImageFormatException saying "Could not load file or assembly 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.QualityTools.UnitTestFramework\v4.0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.".”
This is an issue with MSBuild 4.0 x64 when targeting 3.5 projects. To workaround this you can try one of the following:
- Use the 32 bit version of msbuild by setting “MSBuild Platform”=x86
- Modify the project to include the full fusion name for the 9.0 version of the Microsoft.VisualStudio.QualityTools.UnitTestFramework
- Register the same assemblyfolderEx locations under the 64 bit hive as were registered under the 32 bit hive. This key tells MSBuild to look in the IDE\PublicAssemblies folder where the unit test assembly is- HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\Public Assemblies 9. Create the same key in the non WOW registry hive as well - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\Public Assemblies 9
[Update]
If you are using private accessors in your unit tests, you will see errors when running tests. Adam Root wrote a blog describing the problem and a workaround. We are trying to get this issue fixed for RTM.
Publishing VS2008 test results will fail with a 404 error if you don’t have VS2008 SP1 and the Forward Compat GDR for TFS 2010 installed.
Can I specify TFS Build to use MSBuild 3.5 instead?
This is not possible out of the box. The loggers used by TFS Build are compiled against .NET framework 4.0 and MSBuild 3.5 will fail to load them.