I have provided the entire text file listed below, and also a zip file with the template in a NAnt .build file for download.

Download
Template

Template code:<project name="Killer.NAnt.Template" default="Deploy.Target" basedir="." ><!-- Ian Lintner --><!-- www.dotcodedump.com -->

  <!-- GLOBALS SECTION -->  <property name="Global.Debug" value="false" />    <property name="Global.Project" value="[Project Name]" />  <property name="Global.Email.From" value="[Email Address]" />  <property name="Global.Email.To" value="[Email Address]" />  <property name="Global.Email.Server" value="[Email Server]" />

  <!-- DEPLOYMENT SECTION -->

  <target name="Deploy.Target" description="A generic deployment target" >      <echo message="**************************************************************" />      <echo message="* === Begin Deploy Target 1 ===" />      <echo message="**************************************************************" />      <echo message="* Time: ${datetime::now()}" />      <echo message="**************************************************************" />

      <!--Put Deploy Specific Varaibles Here-->

      <!-- Put Jobs Here -->      <call target="Job.One" />

      <echo message=""/>      <echo message=""/>      <echo message="**************************************************************" />      <echo message="* === End Deploy Target 1 ===" />      <echo message="**************************************************************" />      <echo message="* Time: ${datetime::now()}" />      <echo message="**************************************************************" />  </target>

  <!-- JOB SECTION -->

  <target name="Job.One" >      <echo message="**************************************************************" />      <echo message="* -== Begin Task One==-" />      <echo message="* Time: ${datetime::now()}" />      <echo message="**************************************************************" />

      <!--Put Job Specific Variables Here-->

      <!-- Put Actions Here -->      <call target="Action.One" />      <call target="Action.Two" />

      <echo message=""/>      <echo message=""/>      <echo message="**************************************************************" />      <echo message="* -== End Task One==- " />      <echo message="* Time: ${datetime::now()}" />      <echo message="**************************************************************" />  </target>

  <!-- ACTION SECTION -->

  <target name="Action.One" >      <echo message="**************************************************************" />      <echo message="* Begin Action One: ${datetime::now()}" />      <echo message="**************************************************************" />

      <!-- put tasks here -->      <echo message="   *** Task One ***"/>

      <echo message="**************************************************************" />      <echo message="* End Action One: ${datetime::now()}" />      <echo message="**************************************************************" />

  </target>

  <target name="Action.Two" >      <echo message="**************************************************************" />      <echo message="* Begin Action Two: ${datetime::now()}" />      <echo message="**************************************************************" />

      <!-- put tasks here -->      <echo message="   *** Task Two ***"/>

      <echo message="**************************************************************" />      <echo message="* End Action Two: ${datetime::now()}" />      <echo message="**************************************************************" />  </target>

</project>

View All of the Killer Nant Scripting Articles

Bookmark It

An example of this would be, I have to copy files, but I can’t until I backup my files. You could put the back up call in depends. If you use depends, you lose the ability to call variables in the current task.

How to use <call>:

<!-- Using Depends -->

<target name="task.build" depends="action.build.project, action.copy.to.beta" >

</target>

<!-- Using Call -->

<target name="task.build">   <property name="action.source.dir" value="\\path\to\folder" />     <property name="action.output.dir" value="\\path\to\folder" />     <call target="action.build.project" />     <call target="action.copy.to.beta /></target>

When we use depends, it has to happen before our script runs. Call is more flexible, because you can then scope variables to use with the tasks you are calling, and it does not control the structure of your scripting.

View All of the Killer Nant Scripting Articles

Bookmark It

Extending NAnt one step further you can even create your own custom NAnt assemblies (.dll), for truly flexible tasks. We will focus on doing it in the script, becuase the name of the game is getting it done quickly, without alot of overhead, it’s scripting damnit. If we wanted something else we would just fire up Visual Studio and create a application to do it for us. If you find your self doing extensive amount of programming in NAnt you may want to reconsider NAnt for the task at hand.

<script language="C#" prefix="demo" ><code><![CDATA[ [Function("generateguid")]public static string getguid(  ) {

   return Guid.NewGuid().ToString; }]]></code></script>

<target name="Action.Print.Demo"><echo message="*** My Guid is: ${demo::generateguid()} ***" /></target>

Bookmark It

Logging is logical extension of creating usable output from any type of computer program, be it a windows GUI, a web application, or even a script. Logging allows us to get into the nitty gritty about important steps our programs are executing. This goes one step further into creating really polished, functional scripts. Once we can track what is going on we remove some of the mystery of what is going on.

There are two ways to log, one is through the command line, and the other is the task made available through the NAnt contrib library. The task allows us to save portions of our scripts to files.

To call the record task, we pass it the path of the log file, which we specified with a global variable for the directory, and local action variable and the parameter action=”start” to start the recording task, and then we call it again after the actions we wish to log, and but with the action=”Close” property.

Record Task Example:<!-- Start Logging --><record name="${global.log.dir}\${action.log.file}" level="Info" action="Start"/>

<someaction .../>

<!-- End Logging --><record name="${global.log.dir}\${action.log.file}" action="Close"/>

If you wish to log without using the NAnt contrib library, you can use a simple solution, at the command line redirect the output using ‘>’ . We can redirect the output to a file and save it.

Run our script from the command line normally, but then append > “mylog.txt” to log the output.

Use -e (emacs ouput) to remove some of the excessive NAnt output artifacts.

C:\> nant /f:buildscript.build -e /v:+ all > "mylog.txt"

This will redirect the output of the build script to mylog.txt.

View All of the Killer Nant Scripting Articles

Bookmark It

If you are going to be writing one off scripts, this could be considered a “optional” addition to Nant scripting.

Displaying information well is one the most difficult tasks we as developers face, and with scripting it is very easy to ignore this section. Nant scripts with out well formatted output can be black boxes, that just do a task, and it’s magic. Formatted output and display allows the person using the script to view what is going on, and say “oh it got stuck when copying this file”, “This step was missed”.

Time to get to the scripting.

The output command in Nant is echo:

<echo message="*** I am a formatted Message ***" />

Using echo we can create nice output structures. Here is an example of output to use at the start of an action, and display an important variable called source:

<echo message="**************************************************************" /><echo message="* Task: ${task.name} " /><echo message="*" /><echo message="* Starting Action: ${action.name}: ${datetime::now()}" /><echo message="* Source: ${action.source}" /><echo message="*" /><echo message="**************************************************************" />

We can display information while scripting, that is more useful to the person who needs to run the script. I mostly use these for status updates, and displaying important variables in my scripts, so I can locate exactly what happened, and what is wrong. Good output is rarely appreciated till there is a problem with the script, and exactly what went wrong has to be figured out.

View All of the Killer Nant Scripting Articles

Bookmark It

Jobs are general steps in a deployment process. They can generally be described in one or two words. They will consist of only a couple steps or actions. Examples of job would be: backup, archive, copy application, build, etc.

Jobs may be set up to be generalized, so they can be used in different types of deployment targets. They should have general theme such as moving files, or sections. You may skip jobs if your scripts are simple and require one action, but they are good for providing a level of abstraction, that may be necessary when working on larger scripts.

Job Structure

—> Job Example 1
—-> Call Backup Action
—-> Call Copy Action #1
—-> Call Copy Action #2
—-> Call Clean up Action

An Example Job

<target name="Job.copy.production">

  <!-- Call the actions from your job -->

  <call target="action.copy.bin" />  <call target="action.copy.controls" />  <call target="action.copy.sql" />

</target>

View All Killer Nant Scripting Articles

Bookmark It

The basic structure will move from a top level deployment task to more granular tasks or actions that make up a deployment process. Creating the high level deployment process we can abstract the general task processes. The goal of using a abstracted setup is to create readable and manageable processes.

The high level deployment tasks will determine the general structure of the rest of our nant scripts. The structure can be conceptualized as follows. Our build script will be contain deployment tasks, our deployment tasks will be made up of tasks, and our tasks will divided up into to the smallest element which we call actions.

The most important thing to remeber is that all of these are just a naming convention for nant tasks. We are just creating conceptual division. To create our nant scripts.

Nant Script
Deployment to Production Server
+ Backup
- Archive Current Backup
- Delete Current Backup
- Copy Production to Backup
+ Create Deployment Package

Lets get to the scripting.

The deployment tasks are going to be set up for being easily used, from the command line or a batch file like so:

<target name="deploy.Production" description="Deploy our current build to production">

<!-- First we create our variables to define our paths -->

<property name="property.Archive.Folder" value="C:\Archive"/><property name="property.Backup.Folder" value="C:\Backup"/><property name="property.Production.Folder" value="\\Production\Folder"/>

<!-- Next we call our higher level tasks that are defined later in the script -->

<call target="task.backup" /><call target="task.create.clean" /><call target="task.copy.to.production" />

Our high level task is simply created to call other tasks.

We plug this into our nant file with a heading as before so we have a clearly delineated section

<!--********************************************************************** DEPLOY TASKS********************************************************************* --><target name="deploy.Production" description="Deploy our current build to production">

<!-- First we create our variables to define our paths -->

<property name="property.Archive.Folder" value="C:\Archive"/><property name="property.Backup.Folder" value="C:\Backup"/><property name="property.Production.Folder" value="\\Production\Folder"/>

<!-- Next we call our higher level tasks that are defined later in the script -->

<call target="task.backup" /><call target="task.create.clean" /><call target="task.copy.to.production" /></target>

View All Killer Nant Scripting Articles

Bookmark It

This is not a special nant section, nant allows you to specifiy properties outside of a task, which I am calling global settings. Since I like it nice and verbose I use a big ‘ol header to call attention to it.

<!--********************************************************************** BEGIN GLOBAL SETTINGS*********************************************************************--><property name="package.Company" value="My Company" /><property name="package.Software" value="My.Application" /><property name="package.Result.Email" value="Ian@E.M.A.I.L.com" /><property name="package.Email.Server" value="localhost" /><property name="package.SVN.Program" value="svn.exe" /><property name="package.log.dir" value="..\logdir" /><property name="package.application.dir" value="..\" /><property name="package.project.root" value="C:\root\project\dir" /><property name="Date.Prefix" value="${datetime::get-month(datetime::now())}.${datetime::get-day(datetime::now())}.${datetime::get-year(datetime::now())}.${datetime::get-hour(datetime::now())}.${datetime::get-minute(datetime::now())}" />

<property name="package.task" value="default" />

<property name="debug" value="false" />

View All Killer Nant Scripting Articles

Bookmark It

Nant scripting can be a major headache, especially for beginners. The secret to writing ass-kicking nant scripts is with any coding or scripting is SIMPLIFY. Break your scripts down into functional manageable pieces and you will soon have a killer automation and deployment strategy. Then slap on a few buzzwords and watch your hourly rate sky-rocket.

The basic strategy is outlined below, which I will cover in detail over the next series of posts.

Act I : The Killer Script Structure

1. Settings
2. Deployment Targes
3. Jobs
4. Actions

Act II: Using Nant with the command line

1. Echos and Output
2. Logging
3. Quick Tip

ACT III: All together now.

1. Killer NAnt Scripting Template
2. Concepts and Diagrams
3. Examples and downloads

Bookmark It