WebDeploy with MSBuild Not Deploying from TeamCity

Question

I am trying to use MSDeploy to deploy an MVC project to the server using TeamCity. When I do this on my computer in powershell, using the following command:

msbuild.exe .\mvc.csproj /p:PublishProfile=DevServer /p:VisualStudioVersion=11.0
/p:DeployOnBuild=True /p:Password=MyPassword /p:AllowUntrustedCertificate=true

It builds the project and deploys it to the server (info defined in the DevServer publish profile) perfectly. The output shows an MSDeployPublish section at the end, in which I see text like Starting Web deployment task from source... and then with rows telling me what files are updated, etc.

When I run this on TeamCity, using an MSBuild Build step, on the same file, with the same parameters (from the same working directory) it builds the project but does not publish it. Instead it has the regular output from a build process (CoreCompile, _CopyFilesMarkedCopyLocal, GetCopyToOutputDirectoryItems, CopyFilesToOutputDirectory) but then does not actually go and publish anything.

What changes to I need to make to the setup in TeamCity to get it to publish deploy in the same way that it works using MSBuild from my computer?

(TeamCity 7.1, MSBuild 4.0, WebDeploy 3.0, Visual Studio 12, IIS 7. Related to my previous question)

Haggle

Can you show any parts of your PublishProfile? We've got a good WebDeploy configuration, but we don't use a PublishProfile and I'd like to see if I can make mine fit yours. – Tertius

Sanitized version of the PublishProfile is available here: gist.github.com/7326d2a7f5523058d662 – Haggle

Yaakov, did you abandon using PublishProfile then and use the additional parameters instead? – Serica

Answer 1

We do our WebDeploys with a TeamCity MSBuild step configured as follows:

Build File Path:  Server.csproj

Command Line Parameters:
/p:Configuration=%configuration%
/p:DeployOnBuild=True 
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=https://%web.deploy.server%:8172/MsDeploy.axd
/p:DeployIisAppPath=%web.deploy.site% 
/p:AllowUntrustedCertificate=True
/p:Username=
/p:AuthType=NTLM

We use integrated authentication; change as necessary to fit your scheme. The value of this, I think, is that it builds everything from scratch and doesn't rely on a pre-built package. From the gist you posted I noticed that you do some DB publishing, we don't use WebDeploy for that so I can't offer any guidance there. Hope this helps.

Tertius

No db publishing, just using different connection strings in the web.config depending on the build configuration – Haggle

Gotcha. Something you get for free with the above approach (and maybe with any use of WebDeploy?) is that it'll perform Web.config transforms for you. – Tertius

For some reason WebDeploy does not deploy the dll(s) of referenced projects in the same solution. – Creatural

Answer 2

I use MSBuild.exe to package to zip, and MSdeploy.exe to deploy in separate steps.

To deploy the package.zip file on the command line:

"C:\Program Files\IIS\Microsoft Web Deploy V2\msdeploy.exe" -verb:sync 
     -source:package="C:\Build\MyAppName.Debug.zip" 
     -dest:auto,wmsvc=webservername,username=webdeploy,password=******* 
     -allowUntrusted=true

This command is also worth explaining in detail:

-verb:sync : makes the web site sync from the source to the destination

-source:package="C:\Build\MyAppName.Debug.zip" : source is an MSBuild zip file package

-dest:auto,wmsvc=webservername : use the settings in the package file to deploy to the server. The user account is an OS-level account with permission. The hostname is specified, but not the IIS web site name (which is previously specified in the MSBuild project file in the project properties).

You can modify parameters based on your configuration. I like it this way because with separate steps, its easier to debug problems.

Use TeamCity build step and the command line runner.

Update: If you want an example of how to build the ZIP package using MSBuild, try something like this:

"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
MyWebApp/MyWebApp/MyWebApp.csproj
/T:Package
/P:Configuration=Debug;PackageLocation="C:\Build\MyWebApp.Debug.zip"

This should work the same on your local PC as well as on the CI server.

Competitive

I would be ok with this, but I cant even find anything in the build output of my current step about where it is generating the build package that could then be deployed (this does show up on my computer if I run the same command without specifying VisualStudioVersion=11.0) – Haggle

Are you able to run on the command line locally on the server w/the TeamCity install? You may get additional output. – Competitive

Answer 3

Here are the config settings that finally worked for me:

/p:Configuration=CONFIG-NAME
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=http://SITE-URL/MsDeployAgentService
/p:username="USERNAME"
/p:password=PASSWORD
/p:AllowUntrustedCertificate=True 
/P:CreatePackageOnPublish=True 
/p:DeployIisAppPath=SITE-URL
/p:MSDeployPublishMethod=RemoteAgent
/p:IgnoreDeployManagedRuntimeVersion=True

Haggle

I also had to abandon using PublishProfile and instead use additional parameters as above.. shame really. Not sure why we can't use PublishProfiles in this scenario? – Serica

Answer 4

I had exactly the same issue! I've posted the solution I used over at: MsBuild not finding publish profile

Basics were:

• Install the Azure SDK 1.8 on the build server
• Force the /P:PublishProfileRootFolder value to ensure MSBuild can locate the publish profile

Tippets

In addition to your fix I had to add a system.VisualStudioVersion parameter with a value 11.0. We use a mixture of Visual Studio 2012 and 2013 on the project but only 11.0 worked in TeamCity. If I set it to 12.0 the publish profile was ignored again. – Kirkwall

Answer 5

Ensure that you have the Microsoft Web Developer Tools feature installed for Visual Studio. This was missing on my build agent but once I added it the TeamCity build worked just fine.

Seadog

Answer 6

This can happen when the build target paths are missing from your MSBuild directory. Instead of trying to get those to line up on every developer machine, install the targets from the Nuget. That way it will always be the same for everyone, regardless of how their machine is setup.

Arri