MSBuild: Configurations (4 of 7)

November 29th, 2006

The default configurations for every Visual Studio project are Debug and Release. These different configurations allow you to set different properties which are used during the build, such as the output folder. Naturally the Debug configuration has debug options enabled while the Release does not. But there is much more you can do with a configuration, and you are not limited to just these two defaults. You can copy either of them or start from scratch with a new configuration as shown in the image to the right. Simply open the Configuration Manager in Visual Studio.

Normally I stick to the Debug and Release configurations. But when I work with a build server I like to define a unique configuration which will run a little differently and cause additional work to be done which is not normally done on the developer workstations.

To do continuous integration builds I use CruiseControl.NET which recognizes MSBuild scripts. This tool monitors my source control system and runs a fresh build when changes are made. In these cases I sometimes choose to have the build server run a more thorough build process so I create a configuration called Integration.

The build server is different than the developer workstations. A developer workstation may be a laptop running WinXP with IIS5, Visual Studio 2005, SQL Express, and a single hard drive set up as the C: drive. A typical build server would be running Windows Server 2003 with IIS6, no Visual Studio, just the .NET 2.0 runtime, SQL Server (Standard or better) and at least 2 physical drives, C: drive for the System and D: drive for Data. Isolating those details to the Integration configuration allows for a flexibility with the continuous integration process and a clean separation from the development environment.

Below is the shell of an MSBuild script which accounts for an Integration configuration.

The last target in the script is the IntegrationBuild task which has a couple of attributes controlling its behavior. First, it will only run if the Integration configuration is active due to the expression set on the Condition attribute. Second, it is set to depend on the Build, RunTests, Package and Deploy tasks using the DependsOnTargets attribute. Before any tasks in the IntegrationBuild target are run, each of those targets must be run at least once before those tasks can be run. You do not even have to have any task in the IntegrationBuild target.

Notice also the various PropertyGroup elements at the top. The first PropertyGroup has not Condition attribute and sets the default values and any common properties, such as WebsiteName. In the PropertyGroup filtered for the Integration configuration the DeploymentDirectory property is defined. Since it will only be used for the Integration configuration that property is not defined for the Debug and Release configurations.

Beyond the configuration properties there are settings which you want to be different on the server than the developer workstations, such as web service endpoints and database connection strings. For a website, those are defined in the Web.config by the connectionStrings and appSettings elements. A custom configuration could provide some support to change these values for the tests run on the build server, but there is a better way which is covered next.

More Information:

Next in this series, web deployment projects.

One Response to “MSBuild: Configurations (4 of 7)”

  1. Steven Smith : CCNET with MSBuild and AssemblyInfoTask Says:

    [...] MSBuild and CC.NET Configuration Article – not really related but came up a few times in my search efforts. [...]