Gettinginto MSBuild / TFS Build

As you will no doubt agree, it's handy as heck to be able to get a fresh installer for your app on demand. Right now our build is a relatively manual process that takes a number of hours to complete. It's inefficient and error prone. The answer - automation of course!

I've already set up our environment so that it will automatically build our code whenever somebody checks in - this is a good thing. However, we're thinking about moving to the next step and getting our installer to be automatically built. We're not sure exactly how we're going to do this yet, but the components are:

• Our .NET solution (most of our code is here).
• Some VB 6 code (just enough here to have to make the build interesting).
• An InstallShield installer (and dealing with the InstallShield licensing nonsense).
  

Our main options are:

• Create our own MSBuild setup with custom tasks. Getting this to happen on our build server would be ideal because then anyone on the team could make an installer through the TFS build interface.
  
• Write a .NET app from scratch. Not quite as slick as using MSBuild (considering MSBuild was sort of designed to do just this sort of thing), but I'll take whatever works.
  

Just to keep track of the resources, here are some of the pages I'm looking at:

• This deals with incorporating VB6 and MSBuild
• This has some links for creating custom build steps
• This is getting started with MSBuild

We need to check in some files, so here are some links for that:

• This is some basic info for automating the TFS Version Control.
• Creating a label
  
  

More to come as we narrow down the solution.

Team Foundation Server - Pros and Cons

So you're shopping for a Source Control server. There are a lot of options out there. I've only used two systems in earnest: Source Safe (SS) and Team Foundation Server (TFS). For the most part, I don't hate too many products / technologies. I'd like to think that I'm a pretty open minded guy. However, I truly hate Source Safe. I despise it. I wish that it would go away and never bother anybody ever again. It is a horribly outdated piece of crap technology that should never see the light of day. If you're thinking about adopting Source Safe for a new project, don't. Just stop. Shoot yourself in the foot. It will safe you time and will be less painful in the end. Alan De Smit does a good job detailing why Source Safe sucks in great detail here.

There are a number of other choices out there. I've been particularly interested in trying SourceGear Vault. I've only gotten as far as downloading the trial - I never got around to installing it. I've used their Source Off Site (SOS) product (it's a client / server piece which provides much faster WAN / VPN access to a Source Safe database - it was absolutely brilliant).

But, back to TFS. Here's some background information that should help you get a feel for what you're getting into...

Pros:

• It's fast as hell, at least compared to Source Safe. It's designed to run over a WAN and it communicates with the server via web services. Getting latest is very efficient because TFS only gives you what you need and doesn't need to check every file in your solution.
  
• Integrates ever so nicely with Visual Studio. It fits like a Glove into Visual Studio 2005 / 2008.
  
• Atomic Commits. In other words, if one file doesn't make it into a checkin, none of them make it. That's the way it should be.
  
• Comes with Team Build, which provides functionality that I hear is relatively similar to CruiseControl.net (or so I've heard).
  
• The work item subsystem is pretty sweet. It has lots of features out of the box and is very extensible. This is where you can store bugs, work items, etc. It's not as full featured as Clearcase or one of those systems, but it's adequate for doing most items.
• Pretty solid extensibility. You can add your own check in policies, access the work item / source control via API (either via the client API or through the service interface).
  

Cons

• Costs an arm and a leg. You can get a 5 person workgroup edition (for free with your MSDN subscription), but you'll have to saw off your arm (and leg) to buy enough seats for 6 people.
• Setup is a pain in the ass. There are a bazillion (well, not that many) prerequisites and it takes forever to get them all installed (SharePoint, this, that, etc). Setting up the data tier on another machine takes some work as well. It's definitely not a turnkey, just run Setup.exe and accept the defaults installation.
  
• Because installation is such a pain, recovery is a pain unless you backup the TFS as an image. The good thing is that you only need two things in a worst case situation to restore a TFS server: The SQL Server database backup and the report private key. Well, you can probably live without the key, but the instructions say that you need it.
  
• The work item system in its current implementation does not support hierarchical data. That (very important) feature is supposed to be supported in TFS 2010. IMHO, you need a hierarchy to do a proper breakdown of any non-trivial project. I actually moved all the breakdown information into MS Project (shudder) to get a better breakdown.
• No keyword expansion. This ruffled more than a few feathers as evidenced here. I've never used the feature in Source Safe, but to those who have used it, it is a sorely missed feature.
  
• No sharing of files. This one is a bit annoying. While I've only used sharing sparingly, it's a very handy feature when you need it.
• No shadow folder support. Once again, I've never used this feature. However, if you've depended on it - you'll miss it.
  

There are some notable differences for people that are used to Source Safe, such as:

• TFS keeps track of everything in a Workspace. You have to get all the files that you want to work on before you can do anything. Also, if you don't check out a file in TFS, but you just make it writable, it will likely get overwritten because TFS didn't know that you wanted to do that. This causes all sorts of consternation for long time users of Source Safe. Martin Woodward does a good job of explaining Workspaces here.
• Compares work a bit differently. In Source Safe, if you do a compare of a directory, SS will literally compare every file byte for byte and report any differences (which could take an eternity). On the other hand, TFS assumes that if you haven't checked out a particular file, it isn't different. That's how TFS operates so quickly. Most of the time it works the way you want, but once again, it's different than how it worked in SS.

I'm sure that there are many more pros, cons and differences, but those are the big ones IMHO / experience. Whatever Source Control solution you end up picking, make sure that you trial it to make sure that you can live with it. Once you have a bunch of data in the source control database, it's usually non-trivial to move it to another server.

ProjectGuids in Project Reference

Why is it that it's always the little details that take the most time in any project / implementation? In my recent efforts to get Team Build up and running, I ran into some of the oddest things. The one that had me pulling what's left of my hair out was a very small thing - the .

Normally, in the course of developing a .NET project, you can pretty much ignore the little details like what the projectGuid is for a given project. The problem that I ran into is that one of the project references had an oudated value.

This is the little beasty that was causing all of the issues (this is in the raw xml of the .vbproj file):

<projectReference include="..\MyClassLibrary.vbproj">&
<name>MyClassLibrary</name>
<project>{D5D5C0F8-6BEB-4415-9CA0-E2A84B8D32B6}
<package>{F184B08F-C81C-45F6-A57F-5ABD9991F28F}</package>
</projectReference>

It's rare that a projectGuid will ever change. In this case, we had to make the MyClassLibrary a VSTO plug in for word. I didn't do the conversion (and wouldn't have caught something like the projectGuid changing if I did), but for some bizarre reason we ended up with a new projectGuid for MyClassLibrary.

This is the little bugger that changed in the MyClassLibrary.vbproj file:

{D5D5C0F8-6BEB-4415-9CA0-E2A84B8D32B6}

The fix was simple, all I had to do was copy the correct Guid to the tag of the other project and I was good to go. Finding that was absolutely horrible though.

Along the path, I found out that the solution would actually build after a complete rebuild. Apparently there is some voodoo happening with the ResolveAssemblyReference.cache files. I'm guessing that these "fix up" the references without changing anything in the original .vbproj files. We didn't notice it in our local build environment because these files were already generated with the correct overriding information. However, the build machine always grabs the source to a clean directory, so these files haven't been generated yet.

TFS Team Build

It was the best of times, it was the worst of times. Team Build (as included in Team Foundation Server 2008) is a very powerful tool which can save all sorts of time by automatically building your code every time somebody checks something in. I've never used it, but TFS is supposed to do a lot of the things that Cruise Control.NET does out of the box. That said, it can be a pain tracking down all the resources you'll need to get your solution compiling like a champ. Here's what I did / used.

For the most part, getting started is pretty straightforward. However, there are a few gotchas. In general, you want a dedicated server to do the team builds. To get started with that, you need to install the build agent on that machine. The installation bits are on the Team Foundation Server install disc. The important part here is to set up the build service to run under an account that has access to TFS. If you screw this up the first time, just go into services and change the username / credentials for the "Visual Studio Team Foundation Build" (don't forget to restart the service).

After you've installed that, you need to set up your workspace. I followed Buck Hodge's advice on getting that going.

Now, some special cases. If you are signing any of your assemblies with a .pfx key, you'll want to import that onto the local machine. Here's some advice.

Another item to keep in mind is that the solution will be built with a slightly different folder structure. This can cause problems if you have a post build step that copies files (e.g. if you have some plug in type files that aren't directly referenced by the main application project but the app needs them to run).

This approach work fine on the local machine, but not on the build server. To make something like this:

copy "$(TargetPath)" "$(SolutionDir)MyApp\bin\Debug"

work on the build machine, you can do something like this:

IF EXIST "$(SolutionDir)MyApp\bin\Debug" copy "$(TargetPath)" "$(SolutionDir)MyApp\bin\Debug"

That should work in most cases (your mileage may vary).

I haven't tried setting up an unit tests to run automatically. If / when I'll do, I'll likely post about that too.