Here’re a few helpful tricks for setting up a build environment, finding the most recent version of NUnit and using it with MSBuild Community Tasks programmatically (assuming you’re not checking in NUnit alongside your source code, which you probably should).
We wrap build into a build.cmd that sets up a basic build environment. This avoids users the headache of launching anything except a command prompt upfront. We want a certain version of Visual Studio, targeting a certain version of .NET Framework and NUnit. This is a typical project setup.
Finding Program Files
The first difficulty is to figure out where 32-bit Program Files is. On 32-bit machines this is typically
C:\Program Files and on 64-bit machines,
C:\Program Files (x86). The
ProgramFiles environment variable points to the native Program Files, but we want the 32-bit one.
This one is simple. We want to call vcvarsall.bat for a given version of Visual Studio. This sets up the Visual Studio build environment.
We can simply define the version of .NET Framework and it’s path. In this case we want 3.5, but we could also specify any version available in
NUnit is a bit trickier since we don’t know the version of NUnit installed on this machine. Plus NUnit project has been doing some moving files around. We will define NUnitBinDir and we will also check whether we found it.
NUnitBinDir can be reused with MSBuild Community Tasks in an MSBuild .proj file (in our case we want 32-bit NUnit).
The final step is to setup PATH and shell to MSBuild proper.
I tend to use a stock build.cmd in many projects and it has simplified our life quite a bit. Here’s a complete one. You can type
build all /p:Configuration=Release for example to build the project release configuration.