Starting with Team Foundation System 2010, the engine running build definitions went through an overhaul. Gone away is the MSBuild-based build script. Here to stay (presumably) is a WF/XAML-backed definition.

When I first encountered this change, my reaction was an irrational one. I had put a lot of effort into learning the intricacies of MSBuild, finding extensions to do what I wanted to do, writing custom build actions, etc. I was damn proud that I had morphed the twisted, arcane TFSBuild.proj into something that would filter out files not meant for deployment, make application configurations out of build output, upload NuGet packages, and deploy the build to a continuous integration environment (including configurations for that environment). It was an unholy mess of item groups, cross products, and generally trying to make a declarative language do imperative things. But it was mine. I was the king of that dung heap, and was not going to let it go. Luckily I saw the error of my ways, so consider this a high-level primer of what led me to that decision and why it may be good for you as well. I promise to write more detailed posts on the specifics of some of these things in the future.

The Skinny

I had the opportunity to revisit this when setting up a new coding environment recently, and I’m glad I decided to give it a shot. Even though I had to redo everything from the ground up, it took me maybe a couple days to do everything I was doing before (though I’m using a different system for deployments now). In short order, I had a build system running that:

Builds my solutions
Runs tests
Increments version numbers (through a custom activity)
Fails on test failures (a notable “miss” in the old rat’s nest of TFSBuild)
Filters out debug symbol files, test project assemblies, and .config files from the code projects
Adds default .config and content files to the deployment output
Generates NuGet packages for the newly-built applications
- Scans projects for NuGet packages and includes them as dependencies in the NuSpec file that is generated (custom activity I wrote).
Uploads the NuGet packages to an internal NuGet server.

This was much quicker to build (took about a week, all told, versus lots of tweaking of MSBuild scripts over a much longer period), and is far more visible and stable.

Helpful Tips

Every organization’s system is different, but I can provide with some direction that got me where I’m going. To reiterate my pledge, I will provide deeper articles in the future on subtopics within the build system.

First, Read This

The first thing I looked for was how to customize a build template. When you create a new build definition, it hands you a default template. It is very unlikely that template will be good enough for you, as you will almost certainly want to create your own custom build activities (or use what others have done). I have written activities to filter out files from deployment, apply default configurations, and make/upload NuGet packages, to name a few. This is a good resource in doing customizations: http://msdn.microsoft.com/en-us/library/dd647551.aspx

Define Predictable, Sensible Conventions

The biggest favor you can do for yourself is to have predictable and sensible conventions when organizing your projects and solutions. Just to highlight some of the conventions I favor:

Test projects should be named *.Test. Always.
Use NuGet religiously for dependency management. Only violate that when you have to reference a dependency that must be separately installed (and question why you’re using it in the first place, at that point).
CopyLocal=False, when it comes to external dependencies. Always.
Don’t try to do too much – stick with one framework target and one processor target WHERE POSSIBLE. It can get messy otherwise.

Segregate Your Custom Activities

Just... dont.

Don’t do it. Just… don’t. I learned this the hard way. Put the build activities in a separate code library project, and it all compiles nicely and puts a little icon in your toolbox. Put it in the same project as your XAML file, and everything is not awesome.

Make Sure Trial and Error Won’t Hurt Too Badly

It’s easy enough to roll forward when you screw up a build template. It’s also not hard to make your build system temporarily unavailable due to a bad assembly. Just be prepared to keep an eye on things and react quickly when necessary.

That’s all for now. In the end, Microsoft has made some substantial improvements in the ease-of-use and stability departments, and I’d recommend checking it out and giving it a try.

Using the New (to me) TFS Build