Open Source .NET Development [Electronic resources] نسخه متنی

Why Use NAnt?

NAnt is not the only option for scriptable building of .NET projects. Some other XML-based build tools are Ant, csAnt, and BuildIt. The correct tool completely depends upon your situation and your team's goals. Each of these tools is completely free and comes with source. As always, take the time to review the license to ensure it fits with your intended usage.

Ant

Ant is the original Java-built tool on which NAnt is based. Created by the Apache team, Ant was originated merely as a way to effectively build the Apache Tomcat project. The popularity of an XML-encoded build file took off from there, and today, practically every Java IDE uses Ant. Ant does have a few .NET compiler tasks built in that can be used to build .NET projects. However, according to active members of the Ant development team, this is mainly to support building .NET applications to test .NET and Java interoperation. Therefore, Ant is mainly focused on Java and probably will not expand its support of .NET to the extent of other .NET build tools.

csAnt

Southern Storm Software, Pty Ltd. in accordance with GNU created Portable.NET. In order to build the project, csAnt was created. It has limited functionality but is very similar to Ant functionality. csAnt does not have nearly the functionality and community support that NAnt has but is another perhaps more portable build tool that is written in the C language and therefore does not rely on an existing .NET CLI implementation.

BuildIt

Microsoft teamed with Sapient Corporation (http://www.sapient.com/) to create an automated Visual Studio.NET build tool. This, of course, requires that you use Visual Studio.NET. Using VS.NET can be a slight drawback, in that it requires the user to set all dependencies, targets, and configurations in the Visual Studio.NET (VS.NET) solution file. For large projects, this can be cumbersome. If your team is using VS.NET, you should know that the same functionality of building from the solution or project file is available using NAnt's slingshot or solution task. However, if the team is not committed to learning a new tool (this author has found NAnt much more intuitive than VS.NET's build configuration), then BuildIt can be a good compromise. BuildIt has good integration with Visual Source Safe and allows build logging and emailing of results.

Other Build Tools

Chapter 7, "Continuous Integration," will offer much of the graphical functionality of these miscellaneous build tools.

Overall, NAnt is the best tool for building .NET projects. Even for developers who are familiar with MAKE, I would suggest switching to NAnt. MAKE is not transformable, easily parsable, or extensible. MAKE also does not have .NET-specific tasks built in. If you are used to using an IDE to do your build, NAnt is going to make your life much easier. Although IDEs are time-savers, to change something advanced like building a release build with debugging information to get line numbers is very difficult to explain to someone. It is much easier to just design it into a NAnt build using properties and make it configurable. A NAnt build then should be able to be run on any machine repeatedly. I have found that even the most resistant developers fall in love with NAnt because it is just so cool. Who can resist an XML-based build file that is easy to use and amazingly fast?