Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Customize Your Builds in Visual Studio Using the Standalone MSBuild Tool : Page 2

The build process inside Visual Studio has been redesigned from scratch in Visual Studio 2005, stripped out from the confines of the IDE, and shipped all on its own as a separate tool called MSBuild. And because MSBuild is part of the .NET Framework 2.0, you can start customizing your own build processes and extend them with user-defined tasks.




Application Security Testing: An Integral Part of DevOps

Building an App
Now that you have a basic understanding of MSBuild and its key terms, I'll walk through a simple project file that describes how a traditional C# Hello World program can be built:

<Project MSBuildVersion="2.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/ msbuild/2003"> <PropertyGroup> <AssemblyName>Application1</AssemblyName> </PropertyGroup> <ItemGroup> <Compile Include="HelloWorld.cs" /> </ItemGroup> <Target Name="Build"> <Csc Sources="@(Compile)" OutputAssembly="$(AssemblyName).exe" /> </Target> </Project>

You can start the build process with the command msbuild.exe MyProjectFile.csproj typed from the command line. The project files consist of the element <Project> with the attributes shown in Table 2.

Table 2. The project files consist of the element <Project> with these attributes.




Current version number of MSBuild; currently 2.0 is used.


Lists the Targets that must be created during the build process. Several Targets can be split using a semicolon (;). Each Target listed here must be defined in the project file with a <Target> element. Furthermore you have the possibility to import Targets from predefined project files (each programming language defines its own Targets).

Underneath the element <Project> you can see the elements <PropertyGroup> and <ItemGroup>. Within <PropertyGroup> you can define your properties used within the whole project file. You can reference properties through the syntax $(PropertyName). l<ItemGroup> defines the items that are used during the build process. Here you can define for example which C# files should be compiled.

Each Item array can be referenced through it's name. The name of an array is the name of the XML element used. For example, when you use the element <Compile> then the name of this array is Compile.

An Item group can be referenced with the syntax @(ItemName). All in all there are three different ways to add items to an Item Group. The first way requires you to specify each file that should be added to the specified Item Group:

<ItemGroup> <Compile Include="Source1.cs" /> <Compile Include="Source2.cs" /> <Compile Include="Source3.cs" /> </ItemGroup>

The second way allows wildcards such as *:

<ItemGroup> <Compile Include="*.cs" /> </ItemGroup>

Finally, you can explicitly list your files:

<ItemGroup> <Compile Include="Source1.cs;Source2.cs;Source3.cs" /> </ItemGroup>

The files in an <ItemGroup> are snapshots. So when you create a new C# file during the build process and you have used a wildcard such as * in your project file, the new generated C# file isn’t added to the files in the specified <ItemGroup>.

Checking Conditions
Conditions can be applied to the elements <PropertyGroup>, <ItemGroup>, <Target>, and <Task>. When you are using conditions you must supply an expression that must be evaluated to True or False. In the following example I use a condition to set the output path of the assemblies to bin\Debug or bin\Release depending on the configuration:

<Project MSBuildVersion="2.0" DefaultTargets="MainTarget" xmlns="http://schemas.microsoft.com/developer/ msbuild/2003"> <PropertyGroup> <AssemblyName>Application1</AssemblyName> </PropertyGroup> <PropertyGroup Condition="’$(Configuration)’ == ‘Debug’"> <OutputPath>bin\Debug</OutputPath> </PropertyGroup> <PropertyGroup Condition="’$(Configuration)’ == ‘Release"> <OutputPath>bin\Release</OutputPath> </PropertyGroup> <ItemGroup> <Sources Include="Application.cs" /> </ItemGroup> <Target Name="MainTarget"> <Csc Sources="@(Sources)" OutputAssembly="$(OutputPath)\ $(AssemblyName).exe" /> </Target> </Project>

With msbuild.exe MyProjectFile.csproj /p:Configuration=Release you can start the build process and specify the appropriate configuration.

I have already mentioned that it is possible that Tasks can communicate with each other through a loosely coupled-architecture. Tasks can create Output Items that can be consumed from other Tasks as Input Items. The code that follows illustrates this concept: The C# compiler creates an assembly used by the Task Copy to move it to another folder.

<Project MSBuildVersion="2.0" DefaultTargets="MainTarget" xmlns="http://schemas.microsoft.com/developer/ msbuild/2003"> <ItemGroup> <MainApplicationSources Include="Application.cs" /> </ItemGroup> <Target Name="MainTarget"> <Csc Sources="@(MainApplicationSources)" OutputAssembly="Application1.exe"> <Output ItemName="ResultingAssembly" TaskParameter="OutputAssembly" /> </Csc> <Copy SourceFiles="@(ResultingAssembly)" DestinationFolder="LatestBinaries" /> </Target> </Project>

As you can see, the Output Items must be explicitly defined within the Task. Therefore the element <Output> exists. With the attribute ItemName you can define the name with which another Task can refer to that Output Item. Additionally you must set the Attribute TaskParameter, which defines which property from the Task is exposed as an Output Item.

Table 3 describes the new XML tags you'll be using with this project.

Table 3. XML tags control the MSBuild process.




Defines the root element of the project file.


All properties are defined within this element.


Items that should be processed from Tasks are defined within this element.


Defines a target that should be built like an assembly.


Represents a Task that should be executed during the building of a target.


Use this element to output Items from Tasks to other Tasks as Input Items.


Use this element to register your own written Tasks within MSBuild.



Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date