The main purpose of a build process is to build an application. A build process should collect all of the pieces of an application and create a deployable package for this specific version. By making this a process of its own, you add both reliability and predictability.
Beyond a predictable build, a number of tools have been introduced that allow for other automated tasks to be run. In a team development environment, the build process would typically bring together code from a number of developers. That makes build time the ideal place to run tasks such as unit tests, and documentation creation. Having these tasks automated in the build can increase the quality of your code and offload some important tasks from the developers.
In addition to adding value to builds, you also have the facility to track and report on the builds. When configured to trigger on a check into source control, your development team can receive unit test results via e-mail within minutes of any given change. This allows developers to react quickly to changes while they are still thinking about the change.
The reporting also includes the results of a check against the coding standards. This allows code reviews to focus on code instead of standards.
Below is a list of the packages that will be used, a brief description of each package and how it will be utilized.
Nant (http://nant.sourceforge.net/)
NAnt is the platform that will be used to create the actual build process. NAnt is an open source package modeled after Ant for Java. NAnt will be responsible for the actual building, as well as triggering any other tasks that will be run throughout the build process.
NAntContrib (http://nantcontrib.sourceforge.net/)
NAntContrib is a collection of add-on tasks for NAnt. NAntContrib is also an open source package. NAntContrib adds tasks for vss, the gac, ngen, and many nice tasks. NAntContrib will be used to communicate with VSS.
NUnit (http://www.nunit.org/)
NUnit is an open source unit testing framework for .NET and is modeled after JUnit for Java. NUnit allows developers to create test fixtures and write unit tests for their applications. NUnit includes a GUI and a commandline tool, as well as a set of attributes you add to test assemblies. NUnit will be used to unit test the class library in this article.
NDoc (http://ndoc.sourceforge.net/wiki)
NDoc is an open source package that creates API documentation from XML documentation files from Visual Studio .NET or packages like VBCommentor. NDoc allows developers many options when creating documentation and also comes in GUI and command line flavors. NDoc will be used to create HTML and chm documentation of the application.
CruiseControl.NET (http://ccnet.thoughtworks.com)
CruiseControl.NET ("CCNet") is an open source package used for Continuous Integration and build process reporting. Continuous Integration is a practice of creating a new build once updated files have become available, thus creating a continuous build process. Assuming tasks like unit testing are included in the build process, this allows teams to identify and fix bugs very quickly, provided there is good coverage in the unit tests of course. CCNet will be used to trigger and report on the build process.
FxCop (http://www.gotdotnet.com/team/fxcop/)
FxCop is a package distributed by Microsoft to enforce coding standards. FxCop automates the process of analyzing code for coding standards. This allows peer review sessions to really focus on code and not waste time on things like correcting casing or naming violations. FxCop will be used to analyze the coding standards in the application.
Visual Source Safe (http://www.microsoft.com/vstudio)
Visual Source Safe ("vss") is a source control package distributed by Microsoft. VSS is commonly used for source control when using Visual Studio .NET. It's used here because of its wide availability and adoption, but the concepts in this article would translate to most other source control systems by changing a couple elements in the NAnt file.