How do I speed up Nant Builds?

Question

We have a number of Nant scripts which compile .NET code. These builds are taking 5 - 10 minutes to run, and I would like to find a way to speed them up.

Our Nant script looks something like

<target name="compile.XYZ" description="Compiles the source code">  
    <msbuild project="${src.dir}\XYZ.sln" verbosity="${build.verbosity}">
        <property name="Configuration" value="${build.config}" /> 
        <property name="OutputPath" value="${build.fullpath}/${prefix.xyz}" />
        <property name="ReferencePath" value="${assembly.dir}" />
    </msbuild>
</target>

They are all quite similar to this. I did investigate for nant but it looked a little out of date so I'm a bit hesitant to use it, although this could be quite handy as we do have multiple targets in our build.

Any help you could provide in improving the performance of these builds would be greatly appreciated!

Thanks :)

Answer 1

One of the things to look out for with any build system is to ensure its aware of all dependencies. In your case you are mixing build systems, which is fine but you have to make sure both Nant and MSBuild know your dependencies. If you have two interdependent solutions it may be beneficial to move those dependent projects to a solution of their own to ensure they are only being built once during a build cycle.

Make sure you're taking advantage of incremental compilation. If you don't trust incremental builds for release candidates use separate build targets for releases vs. testings and development builds. Also make sure you're using the appropriate compiler settings for the type of build being run.

Any solutions which do not have compile time dependencies on each other can be built in parallel. While MSBuild(3.5 and later) natively supports parallel builds on the same machine, Nant does not (its Java sibling, Ant does however). The one way to compensate for this is to create a master solution file that is only used by the build. This would allow MSBuild to parallelize independent projects. This slightly dated MSDN article list the benefits and drawbacks of different solution/project organization techniques. You can take this to the next level by setting up a build farm and building independent solutions on multiple machines. Most continuous integration servers support this.

Another thing to consider is whether your projects are following the DRY principle across multiple development projects. If two unrelated projects have classes with similar purposes they can be combined into a single class and move to a shared library. By removing code duplication you're not only decreasing maintenance costs you're also optimizing the build process at the same time. Finding duplication in unrelated projects is time consuming if your developers specialize on certain projects.