Home
Somewhere along the way, I got tired of doing the same configuration management tasks on every project I go to. CM.NET is my attempt at collecting a standard set of build and deploy practices that I’ve found to work well in an easy to use library.
CM.NET is envisioned to work with both MSBuild and NAnt, although all of my current effort is on MSBuild since that’s what I’m using at the moment. In both cases, the idea is to create a set of common build scripts and a workflow that enables you to add your custom tasks at the appropriate places, without having to statically define your dependency chain.
- Brandon Byars
- Sharan Karanth
- Rob Park
A standard set of design goals apply to both the MSBuild and the NAnt scripts:
- Each target file is completely self-contained. If it happens to be included alongside the file that defines the workflow, then it will wire itself into the workflow, but it could be used independently of any other script. This introduces some duplication amongst the scripts, as quite often, the same property is used in multiple scripts. Each script should declare the property with a reasonable default if the property isn’t already defined.
- Friendly errors. Have required input properties that have no reasonable defaults verified with an
Errortask. Wait until the last minute to verify the property, as some properties may be set in previous targets, rather than at the beginning (for example, Team City patches the MSBuild project file, so we have a target to change the properties back to the reasonable defaults) - The scripts in CM.NET make no assumption about whether you’re using absolute or relative paths in your build scripts, and the CM.NET scripts should support running them even if the current directory is not the directory containing the project file.
- (MSBuild only): All dependencies are imported using
UsingTask, to avoid duplicateImportstatements. - (Deploy only): No production directories are ever overwritten. Instead, new directories are created, and a “symlink”-like approach is used to wire up the new production directory as appropriate (e.g. changing the physical directory in IIS to point to the new directory). Old directories will be cleaned up as needed.
The glue for MSBuild is a file called MasterWorkflow.targets. It defines a target called Build that defines the standard workflow, without specifying what is in each step of that workflow. Instead, each step calls a series of targets stored in properties – for example, Compile calls the properties $(PreCompileTargets), $(CompileTargets), and $(PostCompileTargets) in order. Other scripts, including your build, link into the workflow simply by appending to one of those properties