posted on 07 February 2013

1 comments

Getting started with MSBuild

TAGS: MSBuild

Software is, by nature, extremely fragile. One setting configured incorrectly can bring a system to a grinding halt and have a disastrous effect on the people and businesses that rely on it.

On the other hand, software can also be exceptionally reliable. Once a system has been deployed in a live environment for a period of time, it begins to reach a stage where it has dealt with almost every possible scenario and most of  the bugs have been ironed out. The software is now producing reliable and predictable results, and it could theoretically run this way for the foreseeable future. Everyone is happy.

But of course, in the real world, change is inevitable and change, in terms of software, inevitably means disruption. The process of deploying changes to a live environment can be a stressful one. The odds that something could go wrong are stacked against us. When a site like facebook or twitter goes down, the news report that follows almost always mentions some kind of “upgrade” as a contributing factor.

One of the ways in which we can reduce the amount of entropy in our system is to automate the deployment process as much as possible. Although many developers and managers see this as something that increases complexity and takes a large amount of time to set up and maintain, I would argue that the opposite is in fact true.  Once a team becomes familiar with the technology, then a deployment is one click away. Your build process becomes a part of your codebase and therefore enjoys the benefits of becoming more refined and reliable over time.

Today I am going to give you a very brief introduction to the tool we use here at Cergis: MSBuild. If you are using Visual Studio, then you already have MSBuild installed, and it’s already what gets used behind the scenes when you compile your projects. 

1) Let’s start by creating a new web application project.

2) In the root of the site create a new xml file called Build.xml (MSBuild files are in xml format)

3) Replace any existing code with the following:

<?xml version="1.0" encoding="UTF-8"?>

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

  <Target Name="UpdateAssemblyInfo" DependsOnTargets="CleanTrunkBin">

  <Message Text="Updating Assembly Info"/>

    <AssemblyInfo
            CodeLanguage="CS"
            OutputFile="$(MSBuildProjectDirectory)\Properties\AssemblyInfo.cs"
            AssemblyTitle="Mojo"
            AssemblyDescription="Utility class library"
            AssemblyCompany="Cergis Software"
            AssemblyProduct="Mojo"
            AssemblyCopyright="Copyright © Cergis 2012"
            ComVisible="false"
            CLSCompliant="false"
            Guid="91ffec0a-50d8-4813-941e-ed437d92efbd"
            AssemblyVersion="1.0.0.0"
            AssemblyFileVersion="1.0.0.0"
            />
  </Target>

</Project>

4) Open a command prompt and navigate to the folder that contains the Build.xml file that you created.

5) Execute the following command (note that the "Build.xml" is case-sensitive):
msbuild Build.xml /t:UpdateAssemblyInfo

6) You should find that the assembly info has now been updated with the values we provided in the target.

7) Let's add a parameter to our build script. Add the following section above the first target element:

<PropertyGroup>
    <VersionNumber>1.0.0.1</VersionNumber>
</PropertyGroup>

8) Update the assembly version assignments to reference this property:

            AssemblyVersion="$(VersionNumber)"
            AssemblyFileVersion="$(VersionNumber)"

9) Running your script now will set the version number to 1.0.0.1

10) Run the script again, but this time pass in the parameter like this:
msbuild Build.xml /t:UpdateAssemblyInfo p:/VersionNumber="2.0.0.0"

11) Let's add another target to compile the project 

  <Target Name="BuildWebProject" DependsOnTargets="UpdateAssemblyInfo">
    <MSBuild Projects="YOURPROJECTNAME.csproj" />
    <Message Text="*** Finished compiling"/>
  </Target>

Notice how we have specified that our first task will be executed immediately before this one by using the DependsOnTargets attribute.

12) We can also add conditional logic to our tasks by using the "Condition" attribute, for example:

  <Target Name="BuildWebProject" DependsOnTargets="UpdateAssemblyInfo">
    <MSBuild Condition="$(ReleaseNumber)=='2.0.0.0'" Projects="YOURPROJECTNAME.csproj" />
    <Message Text="*** Finished compiling"/>
  </Target>

Every project will have different requirements. Fortunately, there isn’t much that can’t be achieved using MSBuild. You can interact with your version control system, copy and move files around, invoke other processes from the command line, and if that’s not enough – you can even create your own custom tasks. Also be sure to check out the MSBuild Community Tasks open source project on GitHub

Now that you have an idea of how it works, I’m sure you can think of many situations where this level of automation can help make your deployments smoother and less stressful. Eventually you will wonder how you ever shipped your code without it.

Lee

Find out more about Lee here.

1 comments

bodoFaibrak said:

This genuinely answered my challenge, thank you!

add your comment

Email me when other users reply