Up until
Visual Studio 2005 and
.NET Framework 2.0, the actual build process of solution or project files was pretty much a black-box phenomenon for developers. With
.NET Framework 2.0 and
Visual Studio 2005, Microsoft unveiled its new build platform called
MSBuild.
MSBuild essentially provides a transparent build process through
Visual Studio IDE, as well as allows developers to build projects and solutions from the command line. This allows us to fully customize our builds and create builds on machines where Visual Studio is not even installed.
On a recent team project I was using continuous integration or
CI (an Agile practice) via
CruiseControl.NET. It was a breeze to automatically build projects and solutions using
MSBuild on our build server (a run-of-the-mill Dell workstation running Windows XP without
Visual Studio 2005 installed) whenever someone checked-in any files to source control. This allowed us to be confident at all times that various pieces our distributed project integrate well. Moreover, since
MSBuild can build projects and solutions from command line, I had some batch files setup that would build release versions of our projects, create setup files (using
NSIS), archive older versions of setup files, and move new setup files to a network share where MIS / Operations folks could install the new version on the production server from.
In
Visual Studio 2005, project and solution files are nothing more than
MSBuild XML build scripts. This allows us full control over the build process. For example, in a web project,
Visual Studio 2005 does not provide any user interface to modify pre and post build actions. However, since solution file is simply an
MSBuild script, we can modify such actions manually by opening up the solution file in any text/XML editor.
MSBuild can perform several key tasks out of the box. Each task is essentially a unit of work (UOW) that contributes to the entire build process, e.g. copy files and folders, compile files, etc. If we ever require tasks that do not ship with
MSBuild, we can always create custom tasks in any .NET language by simply implementing the
ITask interface or deriving from the
Task class.
In conclusion,
MSBuild allows developers full control of the build process so that builds can be fully customized. This may not be so crucial in smaller projects, but for enterprise solutions that typically comprise of several projects and many dependencies,
MSBuild is definitely a God-send!