I’m assuming you’ve configured your server correctly for WebDeploy 2.0 as per this article:
Configure Web Deploy (IIS.NET)
Note: MS have released a refresh of Web Deploy 2.0 and the original link isn’t really valid any more. I’ve updated this but I think it’ll be a moving target over time.
You also need to install Web Deploy 2.0 on your development/build/CI machine.
If you’re still using 1.0 then I recommend upgrading, there are some huge improvements in 2.0.
Using Visual Studio 2010’s Publish Feature:
Visual Studio can publish a site by right clicking on the site and selecting “Publish”. This brings up the following dialogue:
There are a couple of gotcha’s with Visual Studio 2010 and WebDeploy 2.0. The first is that VS2010 isn’t WebDeploy/MSDeploy 2.0 aware. So if you try to publish you will get an error such as the following:
Error 1 Web deployment task
failed.((04/02/2011 12:30:40) An error
occurred when the request was
processed on the remote computer.)
You’ll also see the following error in the Failed Request Tracing for the web management service on the server in C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1
assuming you have this turned on:
AspNetModuleDiagErrorEvent
Uri /msdeploy.axd
eventData Tracing
deployment agent exception. Request ID
”. Request Timestamp: ’02/04/2011
System.UnauthorizedAccessException: Access to the path ‘D:\’ is denied.
The drive letter will vary according to which drive your IIS site is located on.
Out of the box, the in-GUI Publish mechanism defaults to using the wrong version of MSDeploy (1.0). We want to tell VS2010 to use MSDeploy 2.0. You can do this by editing Visual Studio 2010’s devenv.exe.config
file which is located in (assuming you did a default c:\
drive install):
For 64 bit systems: c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
For 32 bit systems: c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE
Open up devenv.exe.config
in your favourite XML editor (I just used Visual Studio 2010 itself) and copy the following xml:
<dependentAssembly>
<assemblyIdentity
name="Microsoft.Web.Deployment"
publicKeyToken="31bf3856ad364e35" culture="neutral"/>
<bindingRedirect oldVersion="7.1.0.0" newVersion="8.0.0.0"/>
</dependentAssembly>
Add this to the /configuration/runtime/assemblyBinding
section:
Once you’ve done this close all instances of Visual Studio 2010 to allow this change to take effect. Restart VS2010, open a web project and then try to publish again. This time it should be successful.
Publishing using a Build Package:
Visual Studio can produce a Build Package that can be executed from the command line. This is generated using Project -> Build Deployment Package
. Handy for continuous integration and the like (the package can also be generated using msbuild with the /t:Package
switch).
The output folder for the package usually defaults to obj\Package
.
Unfortunately Visual Studio 2010 gets this a bit wrong and generates a msdeploy wrapper batch script targetting 1.0 and targetting deployment at the server rather than site level.
There’s no quick fix for this other than to craft your own msdeploy.exe command line. I’ve split this across several lines to make this a bit more readable.:
"C:\Program Files\IIS\Microsoft Web Deploy v2\\msdeploy.exe" -source:archiveDir="d:\sites\DemoApp\obj\Package\Archive" -dest: auto, computerName="https://yoursite.com:8172/msdeploy.axd?site=yoursitename", userName="demosite", password='somepassword', authtype="basic", includeAcls="False" -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:"d:\sites\DemoApp\obj\Package\Archive.SetParameters.xml" -allowuntrusted
The first thing to note is the path to msdeploy.exe
. Visual Studio generates a path to version 1.0. I’ve changed this to use 2.0.
Notable parameters:
-source:archiveDir=
tells msdeploy we’re deploying a package and provides the local location
computerName="https://yoursite.com:8172/msdeploy.axd?site=yoursitename"
– this tells MSDEPLOY to deploy to a specific site on IIS7. yoursitename
should exactly match the name of the site in IIS.
userName
and password
are is the name of the delegated manager user for the site. This is configured using the “IIS Manager Permissions” feature at the site level. The account needs to be a local Windows user account.
-authtype="basic"
– this forces basic authentication otherwise NTLM authentication is attempted.
-allowuntrusted
– this ignores any SSL certificate errors if you use the built-in self signed SSL cert.
If you use that command line then you should be able to deploy to a remote IIS7 server with success.
Publishing Raw Content:
Sometimes we want to just publish some static content (or maybe even a Classic ASP or PHP site) directly from a local folder. We can do this using the following msdeploy.exe
command line:
"C:\Program Files\IIS\Microsoft Web Deploy v2\\msdeploy.exe" -source:contentPath="d:\websites\mysite" -dest: contentPath="yoursitename", computerName="https://yoursite.com:8172/msdeploy.axd?site=yoursitename", userName="demosite", password='somepassword', authtype="basic", includeAcls="False" -verb:sync -allowuntrusted
Again the same rules apply as before for -dest:contentPath
and computerName
.
I believe the MSDeploy version issues will be resolved in SP1 (which I haven’t had a chance to look at yet).
One Final VS2010 Gotcha:
When publishing using Visual Studio 2010, the “Publish” build package causes the ACL’s of the site’s anonymous account to change to Read Only for all files and folders with the exception of the App_Data
folder which is changed to Read and Write.
This can be worked around by adding the following setting to the .csproj
file under each <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
:
<IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>
Or if you’re using msbuild:
msbuild.exe myproject.csproj /t:Package /p:IncludeSetAclProviderOnDestination=False
I found that useful nugget from here:
Skipping setting an ACL in a Visual Studio 2010 deployment package (WayBackMachine link because the original content is no longer available)