Build and publish .Net 2.0 projects with NAnt and the MSBuild task – level 200
When
.Net 2.0 first came out, I was left using the <exec
/> task to call msbuild.exe to build my solution. The NAnt <solution
/> task is specific to .Net 1.1 because Microsoft change the structure
of project files to be MSBuild scripts.
I may be a little behind on this, but NAntContrib now contains a
<msbuild /> task that can either just build your solution or execute an
entire msbuild script. Here is an excerpt from my NAnt build script:
<target name=“compile“>
<echo message=“Build Directory is ${build.dir}“ />
<msbuild project=“src/xxx.sln“>
<arg value=“/property:Configuration=release“ />
<arg value=“/t:Rebuild“ />
</msbuild>
</target>
The task brings the full power of MSBuild to NAnt. At first, I thought about converting the
entire build to MSBuild, but I have so much invested in NAnt that I can’t
justify the effort of conversion yet since we won’t gain anything. For now, we’ll have a mixed build process.
Later when we need to package with ClickOnce, we can use the
<msbuild /> task with the publish target:
<msbuild project=“src/xxx.sln“>
<arg value=“/p:Configuration=${project.config};ApplicationVersion=${project.version}.${CCNetLabel};MinimumRequiredVersion=${project.version}.${CCNetLabel};UpdateRequired=true“ />
<arg value=“/t:publish“ />
</msbuild>
This node builds the ClickOnce deployment package for our
application. CruiseControl.Net executes this NAnt
script, so every time we commit code to Subversion,
we build out the ClickOnce install package and commit it back to SVN and tag
it. No matter what version we need, it’s
right at our fingertips.
By the way, I now always edit my build scripts in VS 2005
since Resharper 2.0 helps
with NAnt scripts. I can rename targets,
find usages, jump from target to target just as I can in code. In short, it has refactoring and navigation
support for the build scripts.
Why not calling MSBuild directly instead of using Nant only to call it?
I don’t call MSBuild directly from CCNet because I do quite a bit of other work with NAnt. My build script is mostly NAnt, but I delegate to MSBuild for the compile and publish steps.
The task accepts both a target attribure and standard nodes as children. This makes its usage clearer (IMO).
Here is your first sample re-written to take advantage of this:
As you can see, its quite a lot easier to read. The target attribute also accepts a comma or semi-colon delimited list of targets.
In additon, you can specify a verbostiy attribute, which is useful to reduce the output (by setting it to “Minimal”). My typical usage is as follows:
Scott,
Thanks for the tip! I’ll update my build script right away.
Jeffrey, I understand you do more things and that is the reason you are using Nant. But for this example it is an extra tool, it doesn’t add any extra functionality.
For people who start with Continues Intergration it can be frustrating.
Most (read all) the things you do with Nant, you can do with MSBuild.
P.J.,
Yes. there is a contrib project for MSBuild that makes the choice between the two less of an issue. This post, however, documents my discovery of the task for NAnt.
I would agree with JPalermo. I too am partial to NAnt . I have invested a lot of time in NAnt. We can do everything we need to with it. We are just setting up Team Foundation wMSBuild. I have tried many of the gui build tools on the market. Microsoft has done well with MSBuild from what I have seen so far. I like the transparency of NAnt and the ease of configuration. You can follow the sequence of events with a nant.build file very easily. There is no guessing on what the build tool is doing behind the scenes. NAnt also integrates well with CruiseControl and MSBuild doesn’t have a scheduler either.
I´m new to the scene, i´m working with a CM with 100+ developers, I dont see how we could manage without Nant.
I disagree, Nant isn´t just an extra tool, is automatizing many of our processes, except my learning process.