We recently moved the xUnit.net source over to Visual Studio 2010 (still targeting .NET 2.0, though). We do automated builds with TeamCity (the server is generously provided by CodeBetter and JetBrains for open source projects).
When we switched to VS 2010, we noticed that our automated build was failing with the following error:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1835, 9): error MSB3454: 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. This build requires Tracker.exe, but it could not be found. The task is looking for Tracker.exe beneath the InstallationFolder value of the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A. To solve the problem, either: 1) Install the Microsoft Windows SDK v7.0A or later. 2) Install Microsoft Visual Studio 2010. 3) Manually set the above registry key to the correct location. Alternatively, you can turn off incremental resource generation by setting the "TrackFileAccess" property to "false".
This error didn't occur on our development machines, because we have Visual Studio 2010 installed, but the CI machine only has the .NET Framework installed. While some people disagree, we are of the opinion (as are the CodeBetter guys) that Visual Studio is not something you should install on your CI machines.
We use an MSBuild file for our CI builds. We needed to make a simple change to the MSBuild file, where it calls the MSBuild task for our solution, to pass this new flag:
<MSBuild
Projects="xunit.sln"
Targets="Build"
Properties="Configuration=$(Configuration);TrackFileAccess=false"/>This made our build succeed (which solved our immediate problem), but I was curious what was going on. Luckily, some fellow Microsofties were able to clue me into exactly what was going on.
The resource compiler performance is dramatically improved by tracking files changes to your .resx files between builds; it's like incremental compilation from the C++ days, but for your resources. Getting this to work requires a tracker application to watch the file access, which is normally only part of the Windows SDK or Visual Studio.
Unfortunately, the Windows SDK isn't available for download yet for .NET 4. We are willing to accept builds that take a little longer than normal on the CI machine, until the CI machine can get the Windows SDK installed.
Hopefully this can help you get your .NET 4/VS2010 projects up and running on CI for the time being!
