Continuous Integration – Why use MSBuild?

I’ve always loved continuous integration.  Usually I use CruiseControl.net for my .NET applications, and really it doesn’t matter which environment you use as long as it supports MSBuild.  But why should you use MSBuild?  There are many alternatives out there, NAnt being the most popular, but they don’t get a lot of support, certainly not as much as Microsoft puts behind MSBuild.  Microsoft is not known for inventing the wheel, they quite publicly take good ideas and do their best to make them better. 

The style of MSBuild is very similar to NAnt, an XML based build script.  Project files in visual studio are now written in MSBuild script.  You can edit them by hand, add pre and post build events if you want to.  The script is very straight forward, if you’ve used Ant before then you’ll be familiar with it.  Create targets, dependencies, run executables and build project files.  Support for building projects and solutions is built in, file system interface is powerful and easy to use.

Item Groups are great, if you want to process a bunch of files but disregard certain file types you can setup an item group that defines the rule.

   1: <ItemGroup>

   2:     <!--This group of files will be published as part of the website.-->

   3:     <MySourceFiles Include="..\WebProject\**\*" 

   4:                    Exclude="..\WebProject\**\.svn\**;..\HotelsCombined.WebUI\**\*.pdb"/>

   5:   </ItemGroup>

The above example shows how to define an item group for a web project that takes all files from the project except the subversion source and the pdb files.  Useful if you want to deploy a site.

   1: <Target Name="PublishDevelopment" DependsOnTargets="Compile">

   2:   <Delete Files="Publish\**\*"/>

   3:   <Copy SourceFiles="@(MySourceFiles)" 

   4:         SkipUnchangedFiles="true"

   5:         DestinationFiles="@(MySourceFiles->'Publish\%(RecursiveDir)%(Filename)%(Extension)')"/>

   6:   <Copy SourceFiles="development.web.config" DestinationFiles="Publish\web.config"/>

   7: </Target>

The above example will take the MySourceFiles item group and copy it to my output directory, then take my development.web.config and replace the web.config.

Properties passed in get pushed up the tree, so if you pass /p:Configuration=Release into the script it will push it up to any build files that you call.

Why use it over another tool such as NAnt?  Well NAnt can do most things that MSBuild can do really and if you do use NAnt you’ll get a lot of community support.  Both are supported by the popular continuous integration environments.

The Clincher

For me it boils down to two things, Microsoft is heavily supporting MSBuild and support is really important to me.  New features will be added and Microsoft will continue to advance the product as they are very heavily invested in it. NAnt has been in beta since 2007.  If I want to be sure that .NET 4.0 will be supported I’ll go with MSBuild.  The other feature is IDE integration.  MSBuild is supported in Visual Studio out of the box, no extensions necessary.  It’s not as important as the support issue, but it’s nice to have.