I'm a solo developer looking into a tool such as MSBuild/NAnt to improve my build process. My project files are starting to get messy with post-build events and there are analysis tools I'd like to run some times and not others. I want to regain order and define everything into a build XML file.

My thoughts for build targets are:

  • Debug Build: Designed for quick compilation and deployment. No code analysis or checks performed.
  • Analysis Build: Performs Debug Build, code analysis and generates documentations.
  • Deployment Build: Compiles with appropriate compiler flags for a release. Also performs same steps as Analysis Build.

Am I on the right track here? What build targets should I be using for .NET development?

+2  A: 

We currently only use CI (continuous integration or debug build) and Release. Debug build only consists of a compile, no code analysis, testing etc.

Release is where all the magic happens (same as they always say in MTV Cribs): versioning, code signing, packaging, compression, obfuscation, documentation, etc.

I can imagine another 'Publish' or 'Deployment'-build target that does a Release and Publish to a test-server, where i decide when the release-version is ready to be pushed to our test-server.

Bart Janson
BTW, just found out that there is no real need for a Publish-build-target. There is a tool called 'TFSDeployer' that does just that, when the BuildQuality of a build is changed, it will start a customizable script. The tool 'TfsDeployer' can be found on Codeplex.
Bart Janson

Some of the following applies more to team development.

I agree with limiting the number of configurations--every configuration adds to the maintenance overhead. So Debug is stripped down, whereas Release has the code analysis etc. However I run CI on the Release build, so that I do not have to do separate CI and Release builds. This also means that any release build problems will be caught by the CI build triggered by check in, so developers get immediate feedback if they have broken the (potential) release. The other thing I do is for release configurations, I change the project settings to treat warnings as errors, as I like code to be warning free; any warnings will then cause the CI build to fail. As Code Analysis creates warnings, this means any violations of the CA rules will also fail the CI build, which means it will get fixed much quicker by the developer, helping to ensure better quality code right from the beginning.