The arrival of the .NET Framework 2.0 introduced many features, including the new build process driven by the Microsoft Build Engine (MSBuild). This article offers an overview of the tool, along with basic examples.
The build process
If you're a C/C++ developer, you will be familiar with build processes via the make command and makefiles that script the process. .NET developers may be familiar with build processes via the freely available open source NAnt tool. This knowledge will come in handy when working with MSBuild, but it is not a necessity.
A defined build process ensures that the software in your development project is built in the exact same manner each time a build is executed. It allows you to specify directories, file locations, dependencies, and so forth. This is accomplished via a build file that outlines the steps. MSBuild utilizes an XML file. Before diving into the details of build files, let's take a closer look at the application.
MSBuild is installed as a standard component of the Microsoft .NET Framework 2.0. While the version may differ, here is the path to the application with the framework installed on my development machine.
In addition, Visual Studio utilizes MSBuild internally when building solutions via its IDE. It utilizes the MSBuild.exe file included with the .NET Framework installation. It is an important detail that Visual Studio utilizes the same build process as included with .NET for the simple reason that you can easily build solutions built with Visual Studio outside of the IDE — that is, from the command line. The project files (.csproj for C#, .vbproj for VB.NET, and so forth) generated by Visual Studio 2005 to build projects are authored in the MSBuild XML format. Now I'll examine the XML format.
Build files are standard XML, so they may easily be edited with your favorite text editor along with Visual Studio. In fact, the syntax follows the format of Visual Studio project files. The build files allow developers to document what items are necessary for a build as well as rules for different platforms and configurations, and rules can be divided into separate files to enforce consistency across different projects. Build files have the following basic elements:
- Items: These inputs into the build system are grouped into item collections based on their user-defined collection names. These item collections can be used as parameters for tasks that use the individual items contained in the collection to perform the steps of the build process.
- Properties: These key/value pairs can be used to configure builds.
- Tasks: These are reusable units of executable code used by MSBuild projects to perform build operations. Microsoft provides an excellent online reference of the available tasks.
- Targets: These elements allow you to group tasks together in a particular order and expose sections of the project file as entry points into the build process.
The full details of every MSBuild option are beyond this article, but there are extensive online resources available.
Listing A is a build file (the project file) generated by Visual Studio. The following listing provides a snapshot of the project file:
- The OutputPath element designates where the output of the build process is saved. In this example, the output of the compile process is sent to the bin\debug subdirectory.
- The OutputType element specifies the type of output generated. In this case, it is a Windows executable (WinExe) for a Windows Forms application.
- An ItemGroup element includes the list of namespaces utilized (referenced) by the project, so the build process loads these items before it tries to compile the code. Likewise, an ItemGroup element defines the namespaces imported into the code.
- Compile elements define and specify the VB.NET files to compile and the order in which to compile them.
- This file was generated by Visual Studio. At the end of the file, it includes two target sections (BeforeBuild and AfterBuild) where you can define custom actions to be added to the process.
You can edit or view any Visual Studio project file via any text editor. Within Visual Studio, you can unload the project (right-click on the project and select Unload) and then edit the project (right-click on the project and select Edit) to view its project file. You can create these files manually for projects not constructed via Visual Studio.
Using MSBuild is as easy as typing a few commands. It uses the following syntax:
MSBuild.exe ProjectBuild_File.proj /command-line_switch
There are various options available with the MSBuild program. Microsoft provides a great online reference of these options. Note that you don't have to use any of the command-line options unless necessary.
The build process in previous versions of Visual Studio was a kind of black box. Developers didn't know how it worked and they couldn't examine it or use it outside of the IDE. Version 2.0 of the .NET Framework changed it with the inclusion of the MSBuild build tool that is also used in the Visual Studio environment. It provides a consistent build process regardless of how or where the code is created.
Do you or your team use a build process for .NET projects? Do you utilize NAnt or other tools? Share your experience with the .NET community by posting to the article discussion.
Miss a column?
Check out the .NET Archive, and catch up on the most recent editions of Tony Patton's column.
Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.
Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a production environment on a daily basis.