Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Basics

Getting Your MSBuilds on Target

Written by Bob Aiello

Monday, 02 March 2009 06:24

MSBuild is Microsoft’s awesome build framework to make your C# (also C++, VB, J#) applications compile and wrap into a deployable package. I have a lot of experience in every aspect of Software Configuration and Release Management. Although, I am always the first to point out that I can be a little slow when learning a new build tool. I have worked with different flavors of Make (e.g. HP-UX, gnu-Make) along with Ant, Maven 1 & 2. MSBuild feels most like Ant, but the integration with Visual Studio is remarkably strong and learning the Microsoft.Net Framework (3.5) has been a key step in getting control of my builds and those of the developers that I support. Read on if you would like to take another few steps, with me, in my journey to become an MS Build gunslinger.

Build and Compile Frameworks
Sometimes, I hate to admit that I really got started with build tools with the VAX VMS Vaxset way back when I was a VMS admin at a large national Radio Network. Unix was just getting started back then and I stayed away from the earliest version because of their notorious security problems. Both Unix and Windows have come a long way since then and so have the frameworks for building robust build and deployment tools. In my view, MSBuild has taken a huge step forward, although it's not trivial to come up to speed and really understand what is going on under the hood. I would like to make this effort a little easier for you. You may want to start with taking a look at my earlier CM Basics Article entitled, "Strolling Through MSBuild."

Integration with Visual Studio
The tight integration with Visual Studio means that you can build a Windows application, ASP.NET based website, or SOA application and automatically have a suitable .csproj file that can be run by your independent Release Management team using your scripts for running MSBuild. Here is an example of my script.

Create your favorite build script

type mybuild.bat

echo off

REM buildit.bat Bob Aiello March 2009

REM these are a few of my favorite build options...

REM - I love to manually clean the build before I get started

msbuild /noconsolelogger /t:clean

REM - Then I usually have a few version of the build command with the

REM - just my favorite in play (the rest are commented out and left in

REM - as a reminder

msbuild /noconsolelogger /t:compile

REM - Rebuilding involves first cleaning and then building
msbuild /noconsolelogger /t:rebuild

Building using your .sln file
The .sln file is used by the Visual Studio interface to manage the project, including compiling and preparing the release. You can build using the .sln file(as shown below), although working with the .csproj file tends to be easier to understand.

C:\Users\bob\Documents\Visual Studio 2008\Projects\CMBasicsTest1>
msbuild CMBasicsTest1.sln /t:Rebuild /p:Configuration=Release

Microsoft (R) Build Engine Version 3.5.21022.8

Build started 3/1/2009 12:24:19 PM.

Project "C:\Users\bob\Documents\Visual Studio 2008\Projects\CMBasicsTest1\CMBasicsTest1.sln" on node 0 (Rebuild target(s)).

Building solution configuration "Release|Any CPU".

Project "C:\Users\bob\Documents\Visual Studio 2008\Projects\CMBasicsTest1\CMBasicsTest1.sln" (1) is building "C:\Users\bob\Documents\Visual Studio 2008\Projects\CMBasicsTest1\CMBasicsTest1\CMBasicsTest1.csproj" (2) on node 0 (Rebuild target(s)).

Creating directory "obj\Release\".

PrepareForBuild:

Creating directory "bin\Release\".

CoreResGen:

Processing resource file "Form1.resx" into "obj\Release\CMBasicsTest1.Form1.resources".

Processing resource file "Properties\Resources.resx" into "obj\Release\CMBasicsTest1.Properties.Resources.resources".

CopyFilesToOutputDirectory:

Copying file from "obj\Release\CMBasicsTest1.exe" to "bin\Release\CMBasicsTest1.exe".

CMBasicsTest1 -> C:\Users\bob\Documents\Visual Studio 2008\Projects\CMBasicsTest1\CMBasicsTest1\bin\Release\CMBasicsTest1.exe

Copying file from "obj\Release\CMBasicsTest1.pdb" to "bin\Release\CMBasicsTest1.pdb".

Done Building Project "C:\Users\bob\Documents\Visual Studio 2008\Projects\CMBasicsTest1\CMBasicsTest1\CMBasicsTest1.csproj" (Rebuild target(s)).

Done Building Project "C:\Users\bob\Documents\Visual Studio 2008\Projects\CMBasicsTest1\CMBasicsTest1.sln" (Rebuild target(s)).

Build succeeded.

0 Warning(s)

0 Error(s)

Time Elapsed 00:00:00.76

So where are the targets anyway
Taking a look at the Common Targets file
C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets
shows a great deal of information about what is going on under the covers of any MSBuild. You should definitely take the time to peruse this file. Here are a few highlights that helped me understand MSBuild a little bit better.

The Build section (main build entry point)

BeforeBuild;
CoreBuild;
AfterBuild

Name="Build"
Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
DependsOnTargets="$(BuildDependsOn)"
Outputs="$(TargetPath)"/>

The Corebuild (calls each of the build targets)
This allows you to understand all of the targets and also how to add your own customization

BuildOnlySettings;
PrepareForBuild;
PreBuildEvent;
ResolveReferences;
PrepareResources;
ResolveKeySource;
Compile;
UnmanagedUnregistration;
GenerateSerializationAssemblies;
CreateSatelliteAssemblies;
GenerateManifests;
GetTargetPath;
PrepareForRun;
UnmanagedRegistration;
IncrementalClean;
PostBuildEvent

Name="CoreBuild"
DependsOnTargets="$(CoreBuildDependsOn)">

The Rebuild Section (run after an initial build)

BeforeRebuild;
Clean;
$(MSBuildProjectDefaultTargets);
AfterRebuild;

BeforeRebuild;
Clean;
Build;
AfterRebuild;

Name="Rebuild"
Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
DependsOnTargets="$(RebuildDependsOn)"
Outputs="$(TargetPath)"/>

Next steps
Understanding the Common Targets file helps us to see how many MSBuild targets are executed. Please make sure that you send me an email sharing your own experiences. I would love to include your favorite tips and tricks in a future article in CM Basics!

Bob Aiello is the Editor-in-Chief for CM Crossroads and a Software Engineer specializing in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is the Vice Chair of the IEEE 828 Standards working group (CM Planning) and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. He is a long standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he serves as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra UniversityUniversity. You may contact Mr. Aiello at raiello@acm.org or link with him at http://www.linkedin.com/in/bobaiello .

Set as favorite

Bookmark

Email this