Step-by-Step Build
MusicLib.build is the master build file and has a default target of "release". Release acts the mainline for the build calling in turn the following build targets:
Clean—Sets up the directory structure.
Build—Calls child build files to create client and business layer.
sql_load—Loads test data into the SQL Server database.
Zip—Runs NUnit tests, and packages the results into a zip file.
Mail—Mails zip file to build master, project manager, your Mom, or whoever else makes sense.
Looking the mainline fragment, you'll note some new Nant tasks:
<sysinfo/>
<target name="clean" description="cleans build directory">
<delete dir="${build.deploy}" verbose="true" failonerror="false"/>
<mkdir dir="${build.deploy}"/>
</target>
<target name="release" depends="clean,build,sql_load,zip,mail">
<tstamp >
<formatter property="DSTAMP" pattern="yyyy-MM-dd"/>
<formatter property="TSTAMP" pattern="HH:mm"/>
</tstamp>
<echo message="Build started at : ${DSTAMP} - ${TSTAMP}"/>
<echo message="CLR Runtime:= ${sys.clr.version}"/>
</target>
<target name="build" description="compiles projects">
<nant buildfile="${build.biz}/MusicBiz.build"/>
<nant buildfile="${build.client}/client.build"/>
<nant buildfile="${build.tests}/MusicTest.build"/>
<copy todir="${build.deploy}" file="${build.biz}/bin/MusicBiz.dll"/>
<copy todir="${build.deploy}" file="${build.client}/build/MusicLib.exe"/>
<copy todir="${build.deploy}" file="${build.tests}/build/MusicTest.dll"/>
</target>
The code fragment introduces the tasks shown in the following table:
|
Task |
Description |
|
tsamp |
Allows you to set date and time properties at run-time. The formatter attributes operate in an Ant-like manner, with pattern formats and property names. |
|
echo |
Writes a message to the console. |
|
nant |
Calls an external Nant build file. |
|
copy |
Copies either an individual file or fileset to a target directory. |
|
sysinfo |
Sets a number of internal Nant properties with system information. I'm using sys.clr.version to display the .NET CLR version. |
The nant task is where my master build calls each child build or process for the DLL, exe, and test DLLs.
Cleaning
I use Nant properties throughout the build process to simplify build file maintenance. We covered these in the first Nant article, but I'll repeat their use here to save your tired memory:
<property name="build.deploy" value="out"/>
Nant will replace any instance of ${build.deploy} with the string "out" (incidentally, this is my target deployment folder). The first step in the build process is to clean the deployment folder and build folders. My master build file has a "clean" target with a couple of tasks, which perform this job:
<target name="clean" description="cleans build directory">
<delete dir="${build.deploy}" verbose="true" failonerror="false"/>
<mkdir dir="${build.deploy}"/>
</target>
The "clean" target introduces the following tasks:
|
Task |
Description |
|
delete |
Deletes folders or files. |
|
mkdir |
Creates directories if they don't exist. |
The "clean" build target is usually called from my "release" target.
Building Dependent Binaries
The master build calls each binary builder in turn. We learned about the basic build process in my initial article; this time we build Visual Basic.NET, as well as C# projects. The MusicBiz DLL, which is written in VB.NET, is located under the MusicBiz folder. MusicBiz.build is the first time we called the VB.NET compiler (vbc.exe). Here is a section of the build file:
<vbc target="library" output="${build.dir}\${basename}.dll"
optionexplicit="true" debug="true" verbose="true" rootnamespace="true">
<sources basedir=".">
<includes name="*.vb"/>
</sources>
<arg value="/reference:System.dll"/>
<arg value="/reference:System.Data.dll"/>
<arg value="/imports:System.Data"/>
</vbc>
My library is little more than a "Hello, World" application; this is reflected in the simplicity of the "library" target. The vbc task deserves a closer look—it has these parameters and elements:
|
Parameter |
Description |
|
target |
Type of build output—either library or exe. |
|
output |
Output filename. |
|
optionexplicit |
Sets the VB.NET OPTION EXPLICIT flag (this is false by default). |
|
debug |
Generates debug code flag. |
|
rootnamespace |
Sets the compiler RootNameSpace flag |
|
Element |
Description |
|
sources |
A fileset of VB.NET source files to compile. |
|
arg |
Arguments to pass to vbc.exe. I use arg to add the required references and import statements. Your reference list will be much longer than this in most cases. |
The C# Windows Forms build file (client.build) remains almost untouched from my first article; except for the addition of a reference to the VB.NET DLL created by MusicBiz.build.
The last binary to build is my NUnit test library (also written in VB.NET). In reality, you may not want to rebuild your test library with each automated build. I like to rebuild all of the binaries because tests often change quite frequently anyway (as new tests are added to the code base). Consider your own build needs and requirements. Excessive or long build times may force you to look at ways of lowering the cycle-time.
The application is now built and ready for testing!
Testing and Wrapping Up
We'll need to reset our test data before we kick off the NUnit tests. You could rebuild the entire database, but I'll just clean out the relevant tables and import test data. Nant does not have a native SQL Server task (unlike Ant), so we're forced to go to the command prompt, calling ISQL. Nothing new here to SQL Server users; pass the connection information and input filename. Here is the code fragment:
<target name="sql_load">
<exec program="isql" commandline="-U ${sql.username}
-P ${sql.password} -i ${sql.load_file}"/>
</target>
As you can see, I'm using SQL Server security rather than trusted for login. You might want to pipe the results of the ISQL call into a log file. Run ISQL with the –h option to get more help about other command-line options.
I rolled my test and zip tasks together into the "zip" target. Nant has a native task for calling NUnit tests, but this seems to be broken with the latest release of NUnit (version 2.0). So, it's back to the old faithful command line, in which I call the NUnit console application (nunit-console.exe) to run the tests. The zip task takes a file, or path name creates a ZIP file output. The following code fragment demonstrates this in action:
<target name="zip">
<exec program="nunit-console" commandline="/assembly:out\${build.tests}.dll"/>
<zip zipfile="${build.tests.results}">
<fileset basedir="${build.deploy}">
<includes name="*.xml"/>
</fileset>
</zip>
</target>
The final step in my build is to use email the results of the build to the build master (me!). Using mail adds flexibility to your process, allowing you to send build and test results to off-site users. You might skip the mail step; instead opting to copy the test results to your project Web site. Users can scroll through the results via Web browsers; assuming that you allow directory listing on the folder. The mail task is very simple to use, as you can see:
<target name="mail">
<mail
from="${mail.from}"
tolist="${mail.tolist}"
subject="Test Results"
files="${build.tests.results}"
attachments="${build.tests.results}"
mailhost="${mail.host}"
message="These are my latest test results. Read and enjoy." />
</target>
Reviewing this section, we introduced these Nant tasks:
|
Task |
Description |
|
exe |
Runs a system command or program. |
|
zip |
Zips a file or fileset into a single compressed ZIP file. |
|
|
Sends an SMTP email. |
I just ran the build process calling the "release" target, and—like magic—I have a new email from someone called "Nant" in my inbox. What a sad life I must lead if my only emails are from Nant.
The NUnit tests produced the following XML file:
<!--This file represents the results of running a test suite-->
<test-results name="D:\InformIt\article3\Source\out\MusicTest.dll" total="2"
failures="0" not-run="0" date="11/11/2002" time="9:50 p.m.">
<test-suite name="D:\InformIt\article3\Source\out\MusicTest.dll"
success="True" time="2.8340752">
<results>
<test-suite name="true" success="True" time="2.8140464">
<results>
<test-suite name="Tests" success="True" time="2.804032">
<results>
<test-case name="true.Tests.TestDixieChicks" executed="True"
success="True" time="2.764" />
<test-case name="true.Tests.TestBadArtist" executed="True"
success="True" time="0.020" />
</results>
</test-suite>
</results>
</test-suite>
</results>
</test-suite>
</test-results>
Due to limitations in Nant (such as no SQL Server or Source Safe tasks), some .NET development shops use Ant (Java-based) rather than Nant as their build tool. Where Ant falls down for .NET development is its lack of support for VB.NET and NUnit—on the other you could call these directly from the command line.
NOTE
The Ant Web site can be found at http://jakarta.apache.org/ant/. You need to have a Java Virtual Machine installed to run Ant.
The SlingShot tool (part of the NAntContrib project) is interesting because it allows developers to convert Visual Studio.NET project files into Nant build files. You can download SlingShot from http://sourceforge.net/projects/nantcontrib. I've had mixed success with this converter, but its still a great way to learn build file format styles.