MSBuild
I usually end up doing the build and release engineering on whatever project I am on, so I’m actually a bit excited by MSBuild. True, it’s a nAnt copy, which is, in turn, a copy of Ant, but what is imitation if not the most sincere form of flattery? (I’m relatively certain that MS didn’t use this line in the anti-trust suit.)
One of the complaints about VS.NET 2002 was its lack of support for a true ‘build’ environment. One could no longer export to nmake, though that was never a preferred solution in the first place. C# and VB were also considerably weakened by the fact that Visual Studio did not support pre and post build events, though VS.NET 2003 later added this ability for C# projects. Elaborate hacks and an elegant VS add on were invented by the community, but it wasn’t an ideal situation. Several people used java’s Ant to build .NET solutions, and the nAnt project was born to copy the idea of Ant to the .NET world. While careful observers will point out that nAnt predates the release of Visual Studio.NET, the project has only recently gained momentum and widespread use.
For those who aren’t familiar with either tool, both nAnt and Ant provide an XML based declarative build environment, with the ability to easily create customizable add-ons. Pretty cool stuff, and much easier to work with than the whole configure / make authoring common in the UNIX and gcc worlds.
nAnt is a pretty nifty project, but it suffers from a major fallback. Its VS.NET integration is tenuous at best, and the team that works on making this happen is really at the mercy of any potential changes to the .sln and .*proj files made by the Visual Studio teams. Many teams that work with nAnt don’t rely on this (fr)agile integration, and instead maintain separate VS.NET and nAnt build solutions. This is, of course, an ideal way to introduce build time bugs when developers make a change (such as adding an assembly reference in Visual Studio) and don’t update the corresponding build file.
Enter MSBuild. Microsoft is making the promise that their development tools will generate build files that the MSBuild engine is able to consume. In addition, these files will be easy to extend, so that you may create your own complex, automated build process completely supported in the Visual Studio environment. Is there a task that Microsoft didn’t include, that you could really use? Do you have to sound the system bell if there is a build failure? Simply write your own Task by extending the Task class. Sound familiar, nAnt users?
In addition, MSBuild will ship on every OS starting in longhorn. Actually, they’ll also be shipping the .NET compilers there, as well. Now my Mom can drop down to the command line and compile her latest VB project without running out and purchasing Visual Studio.NET. Go, Mom!
Expect tool vendors to also start generating their build environments to be completely compatible and extendable using MSBuild, as well. If they don’t, insist that they do. It’s going to make your life so much easier.
Kudos to Microsoft for MSBuild. Once again, “Opening” a proprietary format and making it extensible really paid off here.