views:

4249

answers:

5

There is an excellent PDC talk available here from Vishal Joshi which describes the new MSDEPLOY features in Visual Studio 2010 - as well as how to deploy an application within TFS. (There's also a great talk from Scott Hanselman but he doesn't go into TFS).

You can use MSBUILD within TFS2010 to call through to MSDEPLOY to deploy your package to IIS. This is done by means of parameters to MSBUILD.

The talk explains some of the command line parameters such as :

/p:DeployOnBuild
/p:DeployTarget=MsDeployPublish
/p:CreatePackageOnPublish=True
/p:MSDeployPublishMethod=InProc
/p:MSDeployServiceURL=localhost
/p:DeployIISAppPath="Default Web Site"

But where is the documentation for this - I can't find any?

I've been spending all day trying to get this to work and can't quite get it right and keep ending up with various errors. If I run the package's cmd file it deploys perfectly. If I run WebDeploy through Visual Studio it also works perfectly.

But I want to get the whole deployment running through msbuild using these arguments and not a separate call to msdeploy or running the package .cmd file. How can I do this?

PS. Yes I do have the Web Deployment Agent Service running. I also have the management service running under IIS. I've tried using both.


Args I'm using :

/p:DeployOnBuild=True 
/p:DeployTarget=MsDeployPublish 
/p:Configuration=Release 
/p:CreatePackageOnPublish=True  
/p:DeployIisAppPath=staging.example.com   
/p:MsDeployServiceUrl=https://staging.example.com:8172/msdeploy.axd 
/p:AllowUntrustedCertificate=True

giving me :

C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets (2660): VsMsdeploy failed.(Remote agent (URL https://staging.example.com:8172/msdeploy.axd?site=staging.example.com) could not be contacted. Make sure the remote agent service is installed and started on the target computer.) Error detail: Remote agent (URL https://staging.example.com:8172/msdeploy.axd?site=staging.example.com) could not be contacted. Make sure the remote agent service is installed and started on the target computer. An unsupported response was received. The response header 'MSDeploy.Response' was '' but 'v1' was expected. The remote server returned an error: (401) Unauthorized.

+4  A: 

Unfortunately there is not a lot of info on this at this time. I'll give you some hints at the end of this message though.

About your problem, I've seen this before when I was trying to deploy using MSDeploy and the account that I was running on didn't have the permissions to execute the deployment on the target machine. So you need to take a look at the account that your builds are running under, and see if this account has the rights to deploy to the target machine. If not then you have a few options; grant the build user the rights, or pass the username/password in.

If you want to pass the values in then you will have to define an item named MsDeployDestinationProviderSetting and its metadata will have to contain the necessary values.

So in your project file (or via properties passed in) define something like the following.

<PropertyGroup>
    <UserName>USERNAME-HERE</UserName>
    <Password>PASSWORD-HERE
</PropertyGroup>

About where can you find documentation, like I said before there is not much out there yet. But since the entire Web Publishing Pipeline is captured in MSBuild targets and tasks you can learn alot on your own if you are familiar with MSBuild. If you take a look at the .csproj(or .vbproj) files for web projects created with Visual Studio 2010 you'll notice a statement like the following:

<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />

This imports the file located at %Program Files (x86)%\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets, and this file in turn imports %Program Files (x86)%\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets

So in order to learn this topic in detail right now you have to inspect those files and learn for yourself.

I'm going to be working on something that will be covering these technologies in detail, but it won't be out for quite a while, and I still have a lot to figure out myself about this stuff.

Can you try out the username/password deal and let me know if it worked for you?

Sayed Ibrahim Hashimi
i managed to finally get it working but only through WMSVC and not the RemoteAgent. couldn't get it to connect to remote agent no matter what URL I tried
Simon_Weaver
OK, now that you mention it I think WMSVC is required for https. I didnt take notice to that.
Sayed Ibrahim Hashimi
i'm pretty sure i've tried with or without. i don't really care which I use - I just can't see why the RemoteAgent didn't work
Simon_Weaver
+5  A: 

I had a similar problem and the solution was to have the following parameter:

/p:MSDeployPublishMethod=RemoteAgent

Here are all of the parameters I used.

/p:DeployOnBuild=True /p:DeployTarget=MSDeployPublish /p:MSDeployPublishMethod=RemoteAgent /p:MsDeployServiceUrl=http://my-server-name /p:username=myusername /p:password=mypassword

NOTE: I'm not using DeployIisAppPath because I'm building a solution and trying to build three web applications at once. Also I think your MsDeployServiceUrl should be just http://staging.example.com

It appears that when using InProc (which may be the default) for the MSDeployPublishMethod MSBuild ignores MsDeployServiceUrl and always tries to deploy to the local server. I changed it to RemoteAgent and all three of my web applications deployed successfully. I did notice that the Package file is nolonger contained in the MyWebApplication_Package folder, but that isn't a big deal to me.

Chad Peck
i've tried all kinds of variations for MsDeployServiceUrl. i always get something like this : VsMsdeploy failed.(Remote agent (URL http://localhost/MSDEPLOYAGENTSERVICE?site=staging.example.com) could not be contacted. Make sure the remote agent service is installed and started on the target computer.) Error detail: Remote agent (URL http://localhost/MSDEPLOYAGENTSERVICE?site=staging.rollingrazor.com) could not be contacted
Simon_Weaver
it seems like this should work - but this is pretty much what Vishal had in his talk. the agent service IS definitely accessesible :if I hit http://localhost/MSDEPLOYAGENTSERVICE in the browser then a log entry gets added in C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp\MSDepSvc.log
Simon_Weaver
+4  A: 

Here's the steps that finally worked for me. I wanted to get the working with RemoteAgent, but couldn't get that working no matter what I tried.

You don't have to do exactly like this, but this is how I got it working

  • Configure WMSVC
  • Make sure the service is started
  • Configure an IIS user (click on the TOP MOST SERVERNAME in IIS) and go to 'IIS Manager Users'. I suggest making it different to your windows name.
  • Make sure the user account for WMSVC (LOCAL SERVICE for me) has write permissions to the IIS directory you're using
  • In my case I'm using an SSL certificate (even though it is hitting localhost).

Remember these are all arguments to MSBUILD added within the TFS Build definition

/p:DeployOnBuild=True 
/p:DeployTarget=MSDeployPublish 
/p:MSDeployPublishMethod=WMSVC 
/p:MsDeployServiceUrl=https://staging.example.com:8172/msdeploy.axd 
/p:username=sweaveriis 
/p:password=abcd1234 
/p:DeployIisAppPath=staging.example.com/virtual_directory_name
/p:AllowUntrustedCertificate=True

Note: staging.example.com is actually the local box with a hosts file entry pointing to 127.0.0.1. Localhost would probably work here too.

Useful articles:

Troubleshooting MSDeploy issues

More troubleshooting

Simon_Weaver
+1  A: 

Note that you may also set DeployTarget=Package -- this will prepare the package but not deploy it right away. For more info see this blog post.

zvolkov
A: 

Thank you all!!! I love the smell of an automated build >> deploy in the morning!

One thing I had an issue with was a pesky 401 error when using an IIS User on the remote web server. I changed the build parmeter credentials to be a domain user, who had proper rights, and all went well deplying to the remote server. I have to figure out why the IIS Management User account failed with UnAuth(401)...

Jeff Spicoli