MSBuild Example

It’s been a while since my last blog post, but as promised here is an example of a MSBuild script. I have made a simple .NET 2.0 web application utilizing the MSBuild script.  The web application source code can be downloaded here.

Web Application Folders and Files

• Config – contains the environment (dev, test, prod), user, and machine configurations
• Core – contains the application’s source code
• Library – contains the third party libraries and tools used by the application
• PrecompiledWeb – generated folder containing binaries for the web application
• Publish – generated folder containing NCover and NUnit results
• Web – contains the web application files
• build.bat – batch file used to execute MSBuild script
• main.build - MSBuild script

Executing MSBuild Script

To simplify running the MSbuild script, a batch file has been created to allow the user to specify the MSBuild target to execute and which configurations to use.

Usage

build [target] [environment]

[target] – Specifies the MSBuild target to execute

[environment] – Specifies the environment (dev, test, prod)

Notes

• If the environment is not specified, the build will attempt to use the configurations from <user>.config
  • if <user>.config does not exist, it will attempt to use the configurations from <machine>.config
  • if <machine>.config does not exist, it will use dev.config
• If the target is not specified, the build will use the build target

MSBuild Targets

These are the available targets for the MSBuild file:

• Config – generates the Web.config and App.config based off the specified environment
• Clean - performs a Clean on the solution and deletes the generated folders
• Prepare – generates the folders for NUnit and NCover results
• Compile - performs a Build on the solution
• Test - runs NUnit for the Unit Tests
• Coverage – runs NCover for the code coverage
• Build - default target
• Cruise - Cruise Control target
• CleanDeploy – removes the folders and files from the deployment folder
• PrepareDeploy – performs a Build on the solution
• Deploy - deploys the application’s binaries to the deployment folder

Please take a look over the MSBuild file and feel free to contact me with any feedback.  In my next post, I will walkthrough the elements in the MSBuild file.

<!– Application Configurations –>

<PropertyGroup>

<SolutionFileName>MSBuildExample.sln</SolutionFileName>

<WebDir>Web</WebDir>

</PropertyGroup>

<!– Test Assemblies –>

<ItemGroup>

<TestAssemblies Include=“UnitTests\bin\Debug\MSBuildExample.UnitTests.dll“ />

</ItemGroup>

<!– Build Configurations –>

<PropertyGroup>

<Default>default</Default>

<Dev>dev</Dev>

<Test>test</Test>

<Prod>prod</Prod>

<ConfigDir>Config</ConfigDir>

<DevConfig>$(ConfigDir)\$(Dev).build</DevConfig>

<TestConfig>$(ConfigDir)\$(Test).build</TestConfig>

<ProdConfig>$(ConfigDir)\$(Prod).build</ProdConfig>

<UserConfig>$(ConfigDir)\$(USERNAME).build</UserConfig>

<MachineConfig>$(ConfigDir)\$(COMPUTERNAME).build</MachineConfig>

<PrecompiledWebDir>PrecompiledWeb</PrecompiledWebDir>

<WebOutputDir>$(PrecompiledWebDir)\$(WebDir)</WebOutputDir>

<PublishDir>Publish</PublishDir>

<NUnitPublishDir>$(PublishDir)\NUnit</NUnitPublishDir>

<NCoverPublishDir>$(PublishDir)\NCover</NCoverPublishDir>

</PropertyGroup>

<!– Tool Configurations –>

<PropertyGroup>

<NCoverExplorerToolPath>Library\NCoverExplorer</NCoverExplorerToolPath>

<NCoverToolPath>Library\NCover</NCoverToolPath>

<NUnitToolPath>Library\NUnit</NUnitToolPath>

</PropertyGroup>

Automated Builds

I’ve been on several different projects across various organizations and one thing that I notice consistently is that they do not have an automated build in place for their projects.  Either the developers do not understand the concepts and benefits behind using an automated build or they choose to neglect it because it’s extra work.  Automated builds is an important aspect of a project similar to source control.

What would an automated build do?

• Clean build artefacts
• Build the application binaries
• Tear down and rebuild development and test databases
• Run Unit Tests, Integration Tests, etc.
• Run Code Coverage, Metrics, etc.
• Deploy application to specific environment (i.e. dev, test, prod)
• Recompile libraries and binaries used by the application
• Notifications
• Version application binaries
• Branching / Releasing your application
• Perform daily builds (via scheduled task or Cruise Control .NET)

At the beginning of the project, spend a day or two setting up an automated build to at least clean, compile, and test your application.  As the project matures, when required, you can add extra features such as code coverage, deployment, etc to the build script.  Trust me, starting off the project with an automated build will save you a lot of time and headaches as the project continues.

The benefits of using automated builds are:

• Reduce time and effort to build the application
• Reliable builds of your application at any time
• Avoid tedious, repetitive, and error-prone work
• Reduce the risk of creating unknown dependencies

Some tools to help with automated builds are:

• MSBuild (Bundled with .NET Framework)
• NAnt (Open Source)
• Cruise Control.NET (ThoughtWorks)
• TeamCity (JetBrains)
• Team Foundation Server (Microsoft)

* The tools stated above are for projects built on the .NET Framework.  There are similar and/or equivalent tools for other development platforms.

Hopefully in the next week or two, if time permits, I will post some NAnt and MSBuild samples.