TheServerSide.NET has an older article that's a nice introduction article to Nant, which, if you've read this blog for a while, you'll know I swear by. If you're not familiar with Nant, go read the article. It'll give you a good feel for what you can do with it.

But that's not the point of this post. I've posted enough about Nant introduction articles. I'm still looking for the killer Nant article - one that gets into details of how to do some fairly complicated things with it, but this one does have something I haven't seen anywhere else: standard target names. The article lists out seven of them:

1. Init - Use this to get everything set up. You know, initialize things. Create folders. Get the latest version from your source control software. Things like that.
2. Build - The heart of a build, at least initially. My experience has been that early in a project, this is the most important part of your build, but as the project progresses, it becomes less important. Not because it really is, but because once you get the build part working, you tend to forget. Then as everyone gets used to it (especially if you use continuous integration), it's pretty solid, and people assume that it works.
3. Docs - What's documentation again? Just kidding. This would be the place to make your NDoc help files.
4. Test - If you're sold on unit testing, then this would be the place to run those.
5. Dist - Create all of your distributable files. Early in the project, this might not even be used. You have to build something before you can distribute, so early on, this could be missing, or it could be pretty simple (zip up a few files). Later, as you get a feel for how you plan to deploy your project, this becomes more and more important (this is why the Build target loses importance over time). This is also the "show off" target, in my opinion. When someone asks what you're doing with Nant, this is the target you brag about. For example, on one project, this target does the following: Clean up the source folders, get latest or by label, build in release mode, copy the files to a new location, get the correct config files, and zip it all up so it can be copied to the production server. On another, we built the software, obfuscated it, signed it, created an installer, zipped the files, and copied the zip and installer to a distribution folder, where it could be downloaded. Those are more exciting to talk about than calling the csc compiler.
6. Clean?- Seems pretty obvious. This cleans up all directories that you using - typically the output directories (bin folders, where files get copied to for distribution, etc.).
7. All - This runs all of the tasks - Init, Clean, Build, Docs, Test, and then Dist. This ensures a clean build where, by the end, everything is ready to go.

Like I've said in the past, I do all of these things, but I've never known what to name them. I have my own naming standard, but it's changed over time, so if you look at my old build files, you won't pick out a pattern. Only recently have I really settled on a standard, but having seen this, it might be better to go with something like this so that maybe, someday, if everyone does it, build files will become standard, so you can read any one of them and know what's going on...