Based on a previous post about TFS Build Server Best Practices,I thought I’d share the stack I install and a few of the steps that I go through to get the build server working. Obviously your experiences will be different to mine, and I don’t recommend that you follow this to the letter unless you have a similar set of solutions to build. I’m also going to assume you have Windows Server installed and your build service up and running, there are plenty of blogs and MSDN articles that show you how to set this up.

To be clear, in our projects, we have the follow solutions to build:

We use a service account to run the build service. I always add the service account to the administrators group on the server. Whether this is good practice or not, it’s a little vague, but at least you can get a build server up and running.

We also have a nasty little gotcha w/r/t to strong name assemblies. When we first run a build, we get this error:

“Cannot import the following key file: ........\Security\Certificates\XYZ.pfx. The key file may be password protected. To correct this, try to import the certificate again or manually install the certificate to the Strong Name CSP with the following key container name: VS_KEY_3645476ACDE0CD2A”

The part in red will be unique to the account that is attempting to compile the dlls. The solution here is to

You can clearly see from this list that a mature and complex set of solutions requires considerable amount of software for a build server to work. Essentially, whatever is installed on a dev box should also be installed on a TFS build server for it to work. I’ve heard people talk of cherry picking dlls etc, but that is a seriously unrealistic method of creating a build server.

* If you are deploying the new ispac, then you know that MSBuild does not compile this type of project. There are several ways to get it to compile as part of a larger automated build, which I will cover in my next post.