Why Create Yet Another Build System?

I really like MSBuild, even though, at the time of this writing, I ve had only a few weeks of experience with it. Of course, years of experience with makefiles makes any more elegant build system attractive. At present, there are two alternative build systems in common use ”Make and Ant. It seems natural to compare MSBuild to such alternatives.

Why Not Use Make?

Why develop a new build system when many developers are familiar with an existing one called Make? Make has poor integration of tools into the build system. Make simply executes shell commands. Because of this, there s no inherent ability for one tool to communicate with another tool during the build process. MSBuild creates instances of the Task classes, and tasks can communicate among themselves passing normal .NET types.

Makefiles have an unusual syntax, are difficult to write, and don t scale well, as they get complex for large projects. In addition, tools other than Make cannot easily process a makefile. Tools other than MSBuild can easily generate and parse the XML-based syntax of an MSBuild project.

Finally, Make doesn t really have support for projects. There s no file system abstraction, and no support for cascading properties. Moreover, there s no design-time support for generating a makefile.

Why Not Use Ant?

A similar frequently asked question is why develop a new XML-based build system when there s an existing very successful and rich system called Ant? Ant is a Java, open source build system from Apache.org that pioneered XML-based project files and tasks as the atomic build operation. There s also a great .NET port of Ant called NAnt available from nant. sourceforge .net . On the surface, MSBuild and Ant/NAnt are similar. Both tools use XML as their project serialization format, and both tools use tasks as their atomic unit of build operation. Both tools have their strengths, but when you take a closer look they have different design goals.

Ant made the design decision to place much functionality into a large set of tasks. MSBuild has a different design goal, where similar functionality is encapsulated by the engine (such as timestamp analysis, intertask communication via items, task batching , item transforms, and so on). Both approaches have their strengths and weaknesses.

Ant s model allows developers to extend and control every detail of the build, and therefore it s very flexible. Nevertheless, it also puts a greater responsibility on task writers because tasks need to be much more sophisticated to provide consistent functionality. MSBuild s model lessens the amount of functionality that each task needs to implement. Project authors can therefore rely on consistent functionality across different projects, targets and tasks. In addition, integrated development environments such as Visual Studio can also rely on those services to provide consistent results and a rich user experience, without having to know anything about the internals of the tasks called during the build process.

Similarly, while Ant has the concept of a build script, it does not have the concept of a project manifest that MSBuild has. A build script says how to create a set of files but doesn t provide additional semantics describing how the files are used. A manifest additionally describes the semantics of the files, which allows additional tools, such as an IDE, to integrate more deeply with the build system. Conversely, the lack of a project manifest means a developer can more easily tailor Ant to build new kinds of stuff because there s no constraining schema for the build script.