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

Examples

Using NAnt can be intimidating. That is why I would like to include several examples of building different types of .NET projects. I will try to show off as many of the built-in NAnt tasks as possible. My goal is to give many practical build scripts that can be used in building real life applications.

Simple Exe

Listing 4.10 demonstrates the simplest of NAnt build projects to create an exe file. This simple build is an example included in the NAnt distribution:

Listing 4.10. Simple Build

Starting from the top, the project name is very fitting: Simple. The default target that will be executed is "build." The next line is an example of a property that will be used later in the project. The next target, "clean," will never be executed unless specified from the command line. The build target executes the csc task using the debug property set previously and outputs a file called simple.exe, which is an exe file. Notice the use of filesets for specifying the source files. However, there are a few issues that I have with this simplistic project. First, I would change the "includes" line of the source's fileset to use patternsets. Changing the line to <includes name="*.cs"/> would allow you to add files to the directory and project without affecting the build. This is very useful when adding a component, especially because each Windows Form in an executable typically has its own .cs file. Usually, a file only contains a single class and any related functionality. I would also add a few more properties to make the project much more reusable (Listing 4.11).

Listing 4.11. Simple EXE Build with Properties

While this build may look more complicated, it really is not once the concept of properties is understood. By using properties in this manner, this build file can be used as a template for many other types of builds.

Simple DLL

Listing 4.12 shows just how simple it is to change a build template to compile a different type of project.

Listing 4.12. Simple DLL Build with Properties

This builds all the cs files in the current directory into a dll. Notice the only difference between Listing 4.11 and 4.12 is that target.type and output.type are changed to output a dll.

ASP.NET and Web Services

Building an ASP.NET or Web Service project is essentially just the same as building a simple dll. ASP.NET assumes the dll to be in a bin subdirectory. The biggest difference is that with Web-based products, NAnt can also be useful in deploying the redistributables. While NAnt certainly could be used in installing traditional thick clients, NAnt's ease of use really is displayed best in the Web development environment.

Chapter 6, "Unit Testing."

Listing 4.13. WebService Build

</fileset>

</copy>

</target>
<target name="build" description="compiles the source code">
<mkdir dir="${build.dir}" />
<csc target="${target.type}" output="${output}" debug="${debug}" define="${define}"
doc="${doc}">
<sources>
<includes name="*.cs"/>
</sources>
</csc>
</target>
</project>

After building this project, the Webservice can be tested in Internet Explorer using the auto-generated test page.

Windows Service

Windows Services are the same as a simple exe, but to install the service into Windows, Service Control Manager (SCM) requires the use of the NAntContrib <installutil> task in Listing 4.14.

Listing 4.14. Building and Installing a Windows Service with NAnt

<servicecontrol

machinename="."

servicename="${project.name}"

command="stop"

failonerror="false" />

<servicecontrol

machinename="."

servicename="${project.name}"

command="start"

failonerror="false" />

</target>

<servicecontrol

machinename="."

servicename="${project.name}"

command="stop"

failonerror="false" />

</target>
</project>

Windows Form

A Windows form project is again very similar to a simple exe project, except for the use of license files and resource files. Resource files can also be used in ASP.NET projects, as seen in Listing 4.15.

Listing 4.15. Windows Form Build

</assemblies>

</license>

Listing 4.15 shows the use of a few references, resource files, and an ActiveX OCX control. The use of a license file is simply for illustration in case a third-party assembly requires it; a license file is not very useful here in my opinion.

Unsafe, Interop, and Other

There are so many tasks and so much functionality to apply that I devote an entire chapter to a case study of NAnt and other tools that we will cover in the next few chapters.

Handling Large Products

Remember, architecting a build is much more than just understanding NAnt. Architecting a successful build of a large product containing many projects can be a full-time job. The build, being code, should also have documentation and well thought-out structure. Figure 4-2 is a UML Use Case Diagram showing a simple build. Each of the UML Use Cases actually is a build target.

Figure 4-2. UML Use Case Diagram of the Build.

This is a simplistic build, and this documentation may seem to be overkill, but Chapter 9, "ASpell.NET Case Study," will demonstrate a very complex build in which this forethought is greatly needed. There are a lot of features that could be implemented in a build such as this. For instance, we could use NAntContrib's asminfo task to change the version numbers of the assemblies or other assembly information to all be the same. We could also use the NAnt <touch> task to mark all the files with the exact same date and time. Either of these could be useful in quickly determining what version of a product a customer has.

The biggest challenge in a large product is to create a build that is easily updatable with new NAnt projects. Typically, when checking out the latest version from SCM, the source should be ordered under a single directory on the file system. This may be easy if the source is already ordered that way in SCM but could require some work if the source is in various paths in SCM. There are a few approaches to use when attempting this, but you must keep in mind that the NAnt projects could be interdependent (i.e., referencing each other). One approach could be to use NAnt's <foreach> task to iterate the subdirectories, as in Listing 4.16.

Listing 4.16. Using Foreach to Get All Files in a Directory

This goes through each subdirectory and executes the <nant> task on the default.build file. This also passes in the configuration and target to the subproject. So in this design, there is a Master project that has the "get" task and that knows where everything is in SCM and where it is going on the file system. Then all other tasks are just dummy tasks that are passed on down to the subprojects. Therefore, the subprojects have knowledge about how to build, clean, and lint themselves, but not how to get themselves because you would have already had to get the project out of SCM before running the NAnt build anyway. This fulfills the general build principle that the Master build can conveniently get everything out and structure it for you, but because all other knowledge is self-contained in the subproject, you could also just run the get task of a specific subproject to wherever working directory you want to and build it using its NAnt project. The problem with this approach is that it does not handle inter-project dependencies. This design will happily recurse the subdirectories and build each project, but what if one project depends upon another? Unless the directory structure was such that the projects were built in the correct order, this build will fail.

Another similar approach is the one used by NAnt itself. Yes, NAnt is built using NAnt! This approach is to use the foreach task again but to put the list of projects into an XML file. This file could contain the dependency information and be transformed to the appropriate text file since <foreach> currently only works on text files. Listing 4.18 shows the Master build's XML list of projects to build, complete with dependency information. Listing 4.17 is the Helper Application to transform Listing 4.18 to a projects.txt file, and Listing 4.19 is the actual NAnt Master build project.

Listing 4.17. Helper Application to Order the Master Build in the Correct Order

using System;
using System.Collections;
using System.Diagnostics;
using System.IO;
using System.Xml;
using System.Xml.XPath;
using System.Xml.Xsl;
namespace NAnt
{
class DependancyChecker
{
private static ArrayList al;
private static XmlDocument xdoc;
[STAThread]
static void Main(string[] args)
{
try
{
if(args.Length>0)
{
al = new ArrayList();
StreamReader sr = new StreamReader(args[0]);
xdoc = new XmlDocument();
xdoc.Load(sr);
XmlNodeList projectNodes = xdoc.SelectNodes("/projects/project");
foreach(XmlNode projectNode in projectNodes)
{
ProcessProjectNode(projectNode);
}
sr.Close();
StreamWriter sw = new StreamWriter("projects.txt");
for(int i=0; i<al.Count; i++)
{
sw.WriteLine(al[i]);
}
sw.Close();
}
else
{
Console.WriteLine("A path to the dependency file is required!");
}
}
catch(Exception ex)
{
Console.WriteLine(ex.ToString());
}
}
private static void ProcessProjectNode(XmlNode projectNode)
{
if(projectNode.SelectNodes("dependencies").Count > 0 )
{
XmlNodeList dependencyNodes = projectNode.SelectNodes("dependencies/dependency");
foreach(XmlNode dependencyNode in dependencyNodes)
{
ProcessDependencyNode(dependencyNode);
}
if(!al.Contains(projectNode ["name"].InnerText))
al.Add(projectNode ["name"].InnerText);
}
else
{
if(!al.Contains(projectNode["name"].InnerText))
al.Add(projectNode ["name"].InnerText);
}
}
private static void ProcessDependencyNode(XmlNode dependencyNode)
{
XmlNodeList projectNodes = xdoc.SelectNodes("/projects/project [name='" +
dependencyNode.InnerXml + "']");
if(projectNodes.Count > 0 )
{
XmlNodeList dependencyNodes = projectNodes [0].SelectNodes("dependencies");
if(dependencyNodes.Count > 0 )
{
ProcessProjectNode(projectNodes [0]);
}
else
{
if(!al.Contains(dependencyNode.InnerText))
al.Add(dependencyNode.InnerText);
}
}
}
}
}

Listing 4.18. The XML List of Projects to Build

<?xml version="1.0"?>
<projects>
<project>
<name>middletier\ws</name>
<dependencies>
<dependency>middletier\datalib</dependency>
</dependencies>
</project>

<project>
<name>presentation\widgetapp</name>
<dependencies>
<dependency>middletier\ws</dependency>
</dependencies>
</project>
<project>
<name>middletier\datalib</name>
</project>
</projects>

Listing 4.19. Master Build File

The output of the NAnt exec task (that runs the Helper Application) is a text file that is properly ordered for dependencies. The advantage of using XML to store the list of projects is that it is transformable and you can easily temporarily comment out projects you do not want to build. Target dependencies are handled in the subprojects. Chapter 9 will elaborate on this design in detail.

Open Source .NET Development
By Brian Nantz

Publisher	: Prentice Hall PTR
Pub Date	: August 16, 2004
ISBN	: 0-321-22810-3
Pages	: 504