What should go in an MSBuild Script except compilation?

Question

I'm currently trying to set up CruiseControl.net, and so I wonder how to split up my Tasks.

Generally, I want to run Unit Tests (xUnit.net), Help File Generation (Sandcastle) and FxCop.

Now I just wonder if I should specify a new Target in the msbuild config ("Documentation") and use that to run SandCastle, or if that belongs in a separate script? Also, msbuild is intended for building something, so I guess that ncover, xunit and FxCop should not be part of it, or should they?

What is the intended scope of msbuild?

Answer 1

I have a build script for individual projects, and I simply chain those from a second build file when building a suite... for example, my protobuf-net build file handles versioning (SVN), compilation (MSBuild + NAnt for mono), testing (NUnit), packaging (zip), etc. It is your build process; do what you need ;-p If could also, for example, do deployment and documentation if I wanted.

It also depends on how you work; if you are using CruiseControl, it may handle much of this for you. For myself, I like a command-line "build" step.

Answer 2

Put almost everything into MSBuild scripts, so that you and other developers can run the same steps locally via the command line. Otherwise, when something goes wrong with the build, you have to debug it on the CC server. Not a nice debugging experience. Also, you want to run the build locally before committing to make sure it works.

The few things that I wouldn'T put into MSBuild scripts are:

• SVN update, as CC has to do this anyway, and you usually don't want to update when doing a local build. (Well, I do type svn up && msbuild quite often, but that's so short that I don't need to put this into a script.)
• Creation and publishing of build reports; again this is CC's domain, and not useful locally

As for structuring your MSBuild files, you will want a "master" build script that you can use to build everything or just some targets, e.g.

• MSBuild /t:Build to just build the code incrementally
• MSBuild /t:Rebuild for a clean rebuild
• MSBuild /t:UnitTest to just run unit tests
• MSBuild for the most frequent choice, say, equivalent to t:Build;UnitTest
• MSBuild /t:All to build code, documentation, and setup cleanly, run all tests, and package the results

You can also add "shortcut" targets for popular variations.

Having a single master build file doesn't mean that everything is defined in this single file; you can include other msbuild files, and/or call msbuild recursively to organize your build. For example:

• The master .proj file should be relatively simple; mainly, it should define project-specific stuff like the list of solutions to build, and project-specific overrides
• Let the master file include a single .targets file that contains targets and default properties; strive to keep this project-neutral and reusable.
• If the .targets file becomes too large, split it up into separate files, e.g. one for code, one for help and documentation, one for setup and packaging. Let your main .targets file include those sub-files, so that your .proj file still needs only include one file
• Likewise you can split up the master .proj file if needed, e.g. by subsystem.