What's New in MSBuild in .NET 3.5
.NET 3.5, which ships with Visual Studio 2008 code named "Orcas" brings one big feature we wanted from the start - support for multiple processors. Although this was a lot of work internally, it's easy for you to get the benefits. To switch on the feature, use the ‘/m' switch on msbuild.exe.

MSBuild parallelizes at the project level. To do this safely, MSBuild has to know which projects depend on the outputs of others. It can figure this out by using the "ProjectReference" items that Visual Studio puts in Visual Basic and C# projects. Before you enable a multiprocessor build, make sure you have declared all your dependencies using this tag so that MSBuild can order the build correctly. "ProjectReference" is an item type understood by the Visual Basic and C# build process we ship: if you have a custom build process you'll need to make sure that you implement something similar, using the MSBuild task.

Multiprocessor support required changes to our logging infrastructure, so if you have a custom logger you may want to read about them. If you use the built-in loggers you'll find we've improved the format with specific attention to diagnosing multiprocessor builds.

Another important new feature in .NET 3.5 is the support for multiple versions of the .NET Framework. MSBuild understands the concept of "Toolsets" defined in the configuration files and registry. These are sets of tasks, targets, and properties that can be switched in as a group. We added this to allow you to switch MSBuild .NET 3.5 between the .NET 3.5 tasks and targets and the tasks and targets that shipped with .NET 2.0. There's also a similar concept of "TargetFrameworkVersion" that lets you build assemblies specifi cally to target the 2.0, 3.0, or 3.5 .NET Framework. Take a look at the MSBuild team blog for more information about these.

A new element was added to the MSBuild file format - ItemDefinitionGroup. Using ItemDefinition-Group, you can specify default values for metadata on all items of an item type. For example, you can specify a default WarningLevel metadata value of "4" on items of type "Compile" item, and in your project fi les selectively override this with a different value.

In MSBuild in .NET 2.0, it wasn't possible to modify or remove items once they were created. To get around this it was necessary to copy items selectively from one item list to another using the CreateItem task, which was hard to read and caused an explosion of item types. A similar problem exists for properties. In .NET 3.5 ItemGroup and PropertyGroup can be used inside Targets, so these special tasks aren't needed anymore. There's also new syntax to remove items selectively from item lists and modify their metadata. In some cases this can make the build process much simpler to write.

You'll also see that you can now access registry keys directly in MSBuild using the new "$(Registry: key@value)" syntax.

Finally you should see performance improvements in many scenarios even without multiprocessor support enabled. Incremental builds of relatively large projects have gotten signifi cantly faster in many cases.

Internal Adoption
"Dogfooding" is the strange name that Microsoft uses for using its own projects internally. We always try to use our own products extensively, starting well before they ship, to get feedback and fix issues before any customers encounter them. For example, you won't be surprised to learn that Microsoft's e-mail systems are always running on recent internal builds of Exchange Server. Right from the start we knew that "dogfooding" would be a top priority for MSBuild if we wanted to be a first-class build system. Early on we began an effort to convert the build of the Visual Studio product from nmake and build.exe to use msbuild.exe.

Visual Studio and the accompanying tools are written in several million lines of C++, C#, and VB and over the years its makefile-based build process had become dauntingly complex. The process of converting Visual Studio to use MSBuild took part of the team about two years, but as our tools and build process matured our progress got faster and faster.

The payoff was huge: we discovered and fixed numerous bugs and scalability problems, added some features, and learned a great deal - which will be fed right back into MSBuild. Our goal was to prove that MSBuild could scale to any customer project, and we believe we have achieved that.

Future Directions for MSBuild
You're probably wondering what to expect from future versions of MSBuild. Our plans aren't firm, so it's important to know that these aren't commitments, but a list of some of the features we'd like to ship at some point. We'd welcome information about what you'd like to see to help us prioritize our work: e-mail our team at msbuild@microsoft.com.
•  Native build support. By far our biggest request. This includes the tasks and targets necessary to build Visual C++ projects on the command line and the Visual Studio support to load and modify them just as you can do today with Visual Basic and C# projects. Of course, we'd want to provide a conversion tool to migrate from today's Visual C++ format to MSBuild syntax projects.
•  Make creating tasks easier. We'd like to make it possible to create tasks without compiling - by writing script or XML directly in the targets file, with strongly typed inputs and outputs just like a regular task. These tasks can then be shared by copying and pasting. Extensible dependency analysis. MSBuild today can compare the timestamps of input and output fi les, but you must specify them explicitly. We'd like to discover these directly, even transitive dependencies. We'd also like to make it possible to plug in different kinds of dependency checking.
•  Improved multiprocessor performance both by speeding up the code path and improving our scheduling. Customers have also asked us to provide the option of automatically distributing builds over multiple machines.
•  Improved tooling around MSBuild. For example, better debugging, visualization, and analysis tools for large builds.
•  Move more project formats over to MSBuild. Visual C++, deployment, and Web projects should be based on MSBuild. Outside of Microsoft, we encourage the vendors of software built on the Microsoft platform to transition their project fi les and build process description if they're interested in the features that MSBuild offers.

Summary
We hope this article was a useful overview of where MSBuild is today and our plans for the future. For too long, build has been one of the least glamorous parts of the software development process, but it's our goal to make it exciting and provide developers with big productivity improvements too! We'd love to hear your feedback: we can be reached on the MSBuild forum, which you can reach from http://forums.microsoft.com/MSDN, or on our blog, which you can find at http://blogs.msdn.com/msbuild. If you prefer e-mail, our address is msbuild@microsoft.com.