Using TFS to Build and Deploy during the Build Process with MS Deploy

Often on projects nowadays, having an automated build and deployment process is a must. Depending on the maturity of the environment there are actually a lot of different ways to achieve these goals, but this post is about one of the simplest ways to get going using a minimum amount of brittle batch/command line tools. For the purpose of this article, I’m assuming you want to use MS Deploy to deploy a web application to in house environments.

Ingredients (what you need):

  • TFS and Team Build
  • Web Deploy Installed on Target Servers
  • Comfort with a little XML editing.

Step 1: Install Web Deploy on Server

Using MS Deploy is extremely convenient – you can package up a website and send it to a server and have it installed with dependencies with minimal effort. Before following this post, you’ll want to install Web Deploy on the target servers.

Step 2: Ensure you have the proper “Configurations” to deploy with

Using Solution/Project Configurations. Typically when you create a new project/solution, you get two configurations: Debug and Release. If you’re using Team Build to perform the deployment, it can be helpful to create a configuration per environment: Dev, Test, QA, Production, etc. To do this, right click on the solution and select “Configuration Manager…” Then select <New> in the Active Solution Configuration. It will prompt you for a name and if you want to copy settings from an existing configuration (such as Debug / Release). Pick one of those.

Step 3: Edit your project file manually

Then you need to modify your csproj (or vbproj) file. Normally you’d expect to use the UI to make project property changes, but in this case, these properties have not been given places in the Visual Studio UI yet. Notice how the project file starts out with <PropertyGroup>s – one that is global, and several (one for each configuration). Find the first one in the file and add these lines of XML in the middle.

These settings will be set for all configurations, even “Debug” which is usually the configuration you use for local development. But because the “DeployOnBuild” property is set to false, msbuild doesn’t do anything with these values.

Next it’s time to modify the configuration that you plan to use for deployment. Look in that file, and you’ll find a line like the following: <PropertyGroup Condition= ‘$(Configuration)|$(Platform)’ == ‘Dev|AnyCPU’ >
assuming “Dev” was the configuration you want to deploy with.

Now, we just need to add two lines inside of that PropertyGroup:



DeploymentIisAppPath – this the “Web Site” name and virtual directoy path that exists within your IIS Server. Do not confuse this with physical file system path.

MsDeployServiceUrl – this is the name of the server – which is all you need in this case, MSDeploy automatically uses the default port of 1872 with SSL to connect and deploy this application.

Step 4: Modify your Team Build Definition

Edit the build definition, go to the “Process” tab. Find “3. Advanced” and you’ll find a place to specify “MSBuild Arguments” – just add the following on that line:

/P:CreatePackageOnPublish=true /P:DeployOnBuild=true


This approach is useful only when you need/can deploy and build on the same action. Some environments require build and deployment to be separate actions such that the compiled bits are identical between environments. This solution does not achieve that – you technically should have a build definition per environment in this case. It has the benefit of being very declarative, plays nice with web config transforms, and overall very easy to implement. Lab Management – a feature of VS/TFS is another way to achieve this – when virtualization can be used – and is relatively easy to set up in 2012.

TF400106: Failed to register the build service–with TFS 2012 Installation

Over this weekend, I was upgrading one of my client’s TFS environments from 2010 to 2012.  The process went very smoothly until we got to the Team Build Configuration.  This continued to fail repeatedly on the “Register with Team Foundation Server” step.  In this particular managed environment of my client, the Windows Firewall Service is disabled completely and replaced with other software firewalls. 

A good description of the problem can be found here.  In summary, the installation process is attempting to add a firewall exception; but since the firewall is disabled it fails.  Optimally, this would be just a warning and the installation would continue.  According to Jason Prickett, this is a bug in the installation code – and it would be fixed in a subsequent release/patch of Team Foundation Server.  Now that Update 1 is released, I did the following:

  1. Stop troubleshooting the build service configuration.
  2. Install Update 1 on that TFS Server
  3. Now do the build service configuration through the UI.

All was good.

If you do this, you’ll need to heed Buck’s note as well about restarting the build services and IIS.  But with those two links, I think you can get the environment in solid shape.

Where does the Feedback Client Store it’s data in TFS 2012?

In the latest release of Visual Studio 2012 and Team Foundation Server 2012, Microsoft added new functionality in the client for requesting and providing client feedback from stakeholders.  I’ve had a number of occasions lately where customers are considering using that feedback client, but curious where does this information get stored?

Two words: Work Items. 

You can discover this when creating a new work item query, and you’ll find two new types: