On our project, we are experimenting with continuous integration, and so we set up a build server based on CruiseControl.NET. The server is running on Windows Server 2008, and we try to keep it as clean as possible. Development machines typically run on Win XP.
The project tree contains tools folder which contains copy of NAnt and other tools which are used to run the build (NUnit, NCover, Simian, etc). This way, when a developer downloads project files to development machine, he just runs the build script and same version of tools is used to perform a local build, thus avoiding the risk of using mismatching version of tools. NAnt build script internally uses <msbuild> task to compile the msbuild solutions.
This has all worked great until we recently switched from .NET 2.0 to .NET 3.5. During this, our development machines were updated to Visual Studio 2008, and our build server was updated to 3.5 framework and SDK (we don't install Visual Studio on build server,so we have to install SDK separately after the .NET framework is installed).
This initially created issues with some of our build scripts: builds started failing with error messages pointing to the fact that <msbuild> task doesn't understand format of the solution file (new version is 10 and build complained about understanding only 7 and 9). After updating NAnt to latest version and testing on a dev machine, problem seemed to went away.
However, builds on our CI build server started failing with same error.
After some investigation, it turned out that Visual Studio 2008 installs version 6.0A of Windows SDK. However, standalone Windows SDK installs version 6.1, thus resulting in mismatch between build server and dev machines.
The heart of the problem is that nant.exe.config internally uses ${sdkInstallRoot} variable which is initialized to the value read from the registry key SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\WinSDKNetFxTools\InstallationFolder. Now, we couldn't just change the entry in nant.exe.config because the same file is used both on server and dev machines, and if we fix it for one it won't work for the other.
We also didn't want to install Visual Studio 2008 on build server.
The solution (or more precisely, the hack) was simple:
- Open regedit
- Go to 'SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.1\WinSDKNetFxTools\InstallationFolder' key
- Export it into a file
-
Open the file and replace all references in key names from "v6.1" into "v6.0A". Leave the file paths with 'v6.1' unchanged.
-
Save the file and import it into regedit
Now you have the exact copy of the SDK 6.1 keys, saved under 6.0A key. This way, build server can use the same nant.exe.config file as dev machines.
If there is a cleaner way, I would be glad to hear it, but this is working for us without any problems.