[Also see Running MSDeploy to a remote box from inside a TFS 2010 Build (Part 2)

A fellow MVP Ewald Hofman wrote a great post on getting an Web Application to deploy as part of a TFS 2010 build. I have been using this technique but found a few points that were not right in the original post, I assume these are down to RC/RTM issues and the fact I was trying to access a remote system.

This is what I had to do

  1. Follow the details referenced by Ewald in the post to create a MSDeploy package, for me the default setting were fine as all I wanted to deploy was a basic web site that had no need for any SQL

  2. Test that this package is works from your development PC to the target web server. If I viewed this publish profile in VS2010 I see the following


  3. Now all these details are stored in a .Publish.xml file in the project root directory. However, this file is not source controlled. It is only for use on the development PC.

  4. You need to set the Site/Application name that will be used when the build server rebuilds this file. This is done by going into the project properties and onto the Package/Publish Web tab. At the bottom of the page set the IIS web application. If you don’t set this the package built will default to the Default Site/ Deploy virtual directory, In my case I just wanted to point to the root of a dedicated II6 hosted web site called Test3.


  5. You now need to got back to Ewalds post. In the build definition you need to add the /p:DeployOnBuild=True MSBuild parameters to cause the package to be created


  6. As he says this causes the package to be created, but not deployed, to do this you need to add a post build event to the project (Or you could edit the Build Process Template to add a PowerShell step at the end, which might be a better option. I have found as I am using a gated Check-in I get the deployment prior to the build doing testing, so potentially I publish something that builds but the tests fail).

    Now this is where I found the most obvious difference in the post, and that is the path. My post build step had the following

    if “$(ConfigurationName)” == “Release” “$(TargetDir)_PublishedWebsites$(TargetName)_Package$(TargetName).deploy.cmd”  /M:http://hunter/MSDEPLOYAGENTSERVICE  /Y

    The first point is that the generated file path and file name is different to that in Ewald’s post. The second point is that he was trying to deploy locally to allow a CodeUI test to run, I wanted the build to be deployed to a simple IIS server (not a clever lab management environment) so I also need the /M: parameter.

    Also remember is that the build agent service user (in my case TFSBuild) must have admin rights on the box you are trying to deploy too, esle the process fails