Chapter 3. Automating the build process


This chapter covers

  • Choosing a build-automation tool for the CI process
  • Using MSBuild
  • Extending MSBuild

Having a single repository that contains everything you need for building your software is the first step on the path to a good CI process. The second, which is also important, is to have the software build. To do this, you need a kind of metaphorical lever that will help you jack up your source code from transcription of ideas into working software. You’ll use this lever in your day-to-day work as well as in the CI process you’re building. Your build lever must be designed in a way that’ll let you build your application in one step.

The first thing that may come to mind as a lever in the .NET Framework world is Visual Studio. It seems to have everything that makes for a good lever. When you press the F6 button, you start a build process that leads to working software. But is it enough? Does it make a good lever? We’re afraid not. It’s able to compile and start a program, but nothing else. We need more to incorporate CI: something that’ll let you test everything, analyze the code, generate documentation, deploy, and create installation routines. We’re looking for something powerful, customizable, and extensible. Visual Studio is a great development environment, but a poor software-automation tool—and we want to automate the entire software build process.

3.1. Build automation

3.2. The Microsoft worker: MSBuild

3.3. The happy couple: Visual Studio and MSBuild

3.4. Extending MSBuild by writing and using custom tasks

3.5. Summary