Imagine you have a buildfile and you have the following compile element that makes use of a couple of third party assemblies:

        <csc target="library" output="${dist.dir}\${app.library.name}" debug="${debug}">
            <sources>                
                <include name="${app.src.dir}\**\*.cs" />                
                <exclude name="${app.src.dir}\**\AssemblyInfo.cs" />
            </sources>    
            <resources>
                <include name="${config.dir}\mapping\*hbm.xml"/>
            </resources>
            <references>
                <include name="${lib.dir}\filehelpers\DotNet 2.0\FileHelpers.dll"/>
                <include name="${lib.dir}\binsor\Castle.Windsor.dll"/>
                <include name="${lib.dir}\log4net\log4net.dll"/>
                <include name="${lib.dir}\nhibernate\NHibernate.dll"/>
            </references>
        </csc>

Pay close attention to the references element. Notice how I am explicitly including the names of libraries that I want to  that "references" fileset.

Most people who are using NAnt are familiar with the concept of a fileset. Essentially it is a set of files that belong to a logical unit that you can make use of during the NAnt build process.

Assume I have another target that needed to perform a similar compile. I could just copy the references element, but that would be unnecessary duplication. What I can do is create a fileset that can be later referenced and used by other targets/tasks in the build file.

I'll start by creating the filset near the top of my build file (before any targets):

    <fileset id="deploy.lib.fileset">    
        <include name="${lib.dir}\filehelpers\DotNet 2.0\FileHelpers.dll"/>
        <include name="${lib.dir}\binsor\Castle.Windsor.dll"/>
        <include name="${lib.dir}\log4net\log4net.dll"/>                
        <include name="${lib.dir}\nhibernate\NHibernate.dll"/>                                
    </fileset>

Notice how I have changed the element to be of type filset vs references. The references element is a special subclass of fileset reserved for the csc task. You will also notice how I have given the fileset an id. It is this id that will allow me to reference this fileset elsewhere. I can now replace the fileset I was originally using in the csc task with a reference to the fileset that contains all of the references that should be used for the compile task:

        <csc target="library" output="${dist.dir}\${app.library.name}" debug="${debug}">
            <sources>                
                <include name="${app.src.dir}\**\*.cs" />                
                <exclude name="${app.src.dir}\**\AssemblyInfo.cs" />
            </sources>    
            <resources>
                <include name="${config.dir}\mapping\*hbm.xml"/>
            </resources>
            <references refid="deploy.lib.fileset"/>                
        </csc>

You can see now that the references element in the csc task now uses the refid attribute to link back to a fileset that I have already defined elsewhere in the build file. Think how many filesets you may take advantage of when building your apps using NAnt:

• sources
• references
• resources

And that is just a small sample. Streamlining and refactoring the build file is just as important as refactoring and improving the code base of the app that the build file is building.

Hopefully this has given you one more tool with which you can go and clean up some duplication that may exist in your build file.