In Steps the 800-Pound Gorilla

In Steps the 800-Pound Gorilla!

For the longest time, up until the release of Visual Studio 2002, Microsoft supported the NMake model of building software. There used to be an option to export makefiles in the VS releases prior to VS 2002, but that option was removed in VS 2002 and will never return. Many decisions went into killing that feature (among the lack of resources needed to maintain the archaic build process), but the main one was to move toward an XML file format such as MSBuild or VCBuild.

MSBuild.exe, the build engine in Visual Studio 2005, is designed to be a scalable .NET build tool that is XML based and able to work independently of Visual Studio. MSBuild's goal is to deliver a platform for build, not just a tool.

VCBuild.exe is a command-line utility that is capable of building Visual C++/C projects and Visual Studio solution files. (You'll learn more later about project and solution files in VS.) VCBuild does not require that Visual Studio is installed. It requires no registration to work, so setup is easy and uninstall is as simple as deleting the bits off the disk. VCBuild also supports such features as multiprocessor builds, output colorization, and the ability to build older versions of Visual C++ projects without having to upgrade the project files (upgrade on the fly).

Devenv.exe (prior to the release of VS 2002/2003, this was called msdev.exe) is the command-line build tool used to build Visual Studio project or solution files. This is opposed to building inside the Visual Studio Integrated Development Environment (VS IDE, or just IDE).

I should stop here and explain what a project or solution file is. This can be confusing even to people who are familiar with Visual Studio.

The best explanation of these files comes from Chris Flaat, a development lead in the Visual Studio core team:

Let's start with projects. Projects can have an arbitrary set of configurations. Think of a configuration as a knob that tells Visual Studio how to build a project. The classic configurations are Debug and Release. For most users, there is no need to go beyond these. However, you might want to define your own project configuration if you want additional ways to build your project (say, with additional diagnostics built in) that don't exactly map to what you want in a debug build or in your final release build.

Understand that a project configuration is a parallel bucket of settings. If you create a new project configuration that copies from the Debug project configuration, you are doing a copy, but any changes you make later to the Debug project configuration aren't reflected in your copy. (The same principle applies to solution configurations.)

Now, what's a solution configuration? Think of a solution configuration as a bucket of arbitrary project configurations. Solution configurations don't have to have the same name as project configurations. A solution configuration is essentially a list of all your projects, where you pick which projects should be included and which configurations should be built. For a given solution configuration, you can pick arbitrary configurations for your projects.

Thank you Chris, now I'll explain why XML is so exciting before I jump into tool recommendations.