Customize Your Builds in Visual Studio Using the Standalone MSBuild Tool

he build process has always been one of the dark mysteries of Visual Studio. What exactly happened when you pressed F5 inside the IDE? Nobody really knew for sure.

This is one of the reasons why Microsoft decided to redesign the whole build process from scratch in Visual Studio 2005. In this upcoming release the whole build process is separated from the IDE and is bundled in a standalone tool called MSBuild. The advantage of this approach is that MSBuild is part of the .NET Framework 2.0 and in the Longhorn timeframe the .NET Framework will be part of the underlying operating system. So you don't need anything in your build lab except a computer running the .NET Framework—there are no other deployment issues, like there are in Visual Studio 2005.

Why should you switch to MSBuild?

• All project files created in Visual Studio 2005 are MSBuild project files.
• MSBuild is designed for scalability, performance, and extensibility.
• You are able to customize the whole build process for your own requirements: as a example you can include functionality from Source Code Control Provider like Visual Source Safe into your build process (e.g. getting the latest version, labeling builds etc.)

You don't need to install Visual Studio 2005 in your build lab. You only need the .NET Framework 2.0.

Project files in Visual Studio 2005 are XML files that describe the whole build process, splitting it up into several fine-grained tasks. The visible part of MSBuild is contained in the console application msbuild.exe, which drives the whole build process. It is a thin wrapper around the core build engine implemented in the assembly MSBuildEngine.dll. This application receives project files as input and processes them synchronously.

Overview of MSBuild
The execution engine of MSBuild is responsible for executing the project files and calling all defined Tasks synchronously. Tasks are part of a so-called Target. You can see a Target as a component that is created during the build process (like an assembly). Tasks can receive their inputs from Properties and Items and can produce so-called Output Items that other Tasks can use as their inputs. Table 1 gives the definitions for these important terms.

Table 1. You should be familiar with these important terms before using MSBuild.

Term	Description
Target	A target is a component that is created during the build process—like an assembly.
Task	A Target can consist of several tasks that describe the workflow used to create the Target. A Task represents a work item that must be executed—think of the compilation of C# files with csc.exe.
Properties	Properties are defined as key/value pairs. Properties are used to configure the build process. An example is the output path of the created assemblies.
Items	Items are lists of objects that can be used for Tasks as inputs. For example, the Task used to call csc.exe retrieves C# files as input items for the compilation.
Output Items	Tasks can produce Output Items that can be consumed from other Tasks as Input Items. Because of the loosely-coupled architecture it is possible to link tasks together written by different vendors in different languages.
Conditions	Conditions are used to drive the build process. With Conditions you can define if Tasks or Targets should be executed during the build process.