Automating Deployment with Microsoft Web Deploy
page 6 of 12
by Scott Guthrie
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 56762/ 105

Using the "Publish Web" Dialog within Visual Studio

Now that we have our web server enabled with Web Deploy, let's try deploying something to it within the Visual Studio IDE.

VS 2010 includes a new "Publish Web" feature that you can use to quickly deploy a web application to a remote server.  You can activate it by right-clicking on any ASP.NET Web Application Project (both Web Forms and MVC varieties), and then select the "Publish" context menu item:

image

Selecting this will bring up a “Publish Web” dialog which allows you to configure publish settings.  You can use this dialog to publish an ASP.NET application to a remote user using FTP/FTPS, Web Deploy, or FrontPage Server Extensions.

We’ll select the “Web Deploy” option from the drop-down, and then enter the publishing information of our Web Deploy server:

image

Note that you only have to fill these settings out once – you can then save them as a “Publish Profile” using the “Save/Rename/Delete” buttons at the top.  Publish profiles allow you to save multiple deployment/publishing options and quickly flip between them depending on what server you want to use.

A few notes about the various options you can specify:

Service URL:

This is the URL of the Web Deploy Management Service.  If you are using Windows Server 2008 the default format of the URL is https://mysite:8172/MsDeploy.axd Note the protocol is “https://” and the port should match whatever you specified when you enabled the IIS Management Service above. 

If you are publishing against a Windows Server 2003, Windows 7, or Windows Vista machine then the default format of the URL is http://server-name/ (not https – since the security credentials are sent using built-in Windows authentication which is encrypted). You also don’t need to specify a port number with Windows Server 2003, Windows 7 or Windows Vista.

Site/Application:

This allows you to specify the site name (and optional application name) on the remote server that you want to install the application to.  You can publish your project as a site, in which case you might specify something like www.mysite.com as the sitename, or “Default Web Site” if you just want to publish at whatever the default root site name is. 

Important: The site name you specify needs to correspond to the same site-name that shows up in the IIS admin tool.  So if you’ve registered the www.scottgu.com site using the friendly name “ScottGu’s Site” or just “scottgu.com” when you created it in IIS you need to make sure the site name you specify as a publish setting corresponds to the friendly name (so you’d specify “ScottGu’s site” instead of www.scottgu.com if that is what shows up in the IIS admin tool as the site name).  If you specify this incorrectly you’ll get an error that says the the remote agent “could not be contacted”.

Alternatively you can publish to a sub-application location using a value like “www.mysite.com/myapplication” or “ScottGu Site/myapplication”.  If the /myapplication vdir and application doesn’t already exist, then the Web Deploy service will create it for you and then publish your project to it. 

You can optionally indicate that you want this sub-path to be a virtual directory (the default) or an application by checking the “Mark as IIS Application on Destination” checkbox.

Credentials:

If you are publishing to a remote server that is not part of your windows domain, then you can specify your username/password in the publish dialog.  This username/password combination can either map to a Windows account on the remote server – or alternatively map to IIS usernames (which enable more flexible locked-down delegation options – which I’ll cover in my next blog post).

Important: Unless you’ve installed a signed SSL certificate on your remote server, make sure you check the “Allow untrusted certificate” checkbox.  By default Web Deploy will install a cert for you to use that is unique (and unsigned) – and if you don’t check this checkbox your login will fail because VS won’t trust an unsigned cert.

Other Notes:

There is a checkbox provided that allows you to indicate whether you want to “Leave extra files on destination” or not.  If you uncheck this then the existing files in the site/application you are publishing to will be deleted if they don’t match what is currently in your VS project.

Once you have filled out the Publish settings, you can click the “Publish” button and it will connect to the remote Web Deploy service and deploy your application to the location you provided.  Your “Output” windows within Visual Studio will show output like below that explains how it was deployed and the actions that occurred with the publish step:

The above project is a basic web project with just a few files and directories within it.  Web Deploy will handle copying all of the file and setting appropriate ACLs on the remote server (for example: making the \app_data directory to be read/write).  In later blog posts in this series I’ll discuss how to enable database deployment as part of the Web Deploy process – as well as how to automatically switch web.config file settings (e.g. connection-strings) as part of it.

And with that we’ve published our site on a remote server.  To re-publish it again you can right-click on the project and once-again select the “Publish” command – which will bring up the publish dialog again (with the same settings as last time populated in it by default). Alternatively, you can enable the “Web One Click Publish” toolbar within VS 2010 – which enables you to quickly switch between saved publishing profiles (using a drop-down) and then click the “"Publish” button to the right of it to public the project to the target server (no dialog required):

Note that Web Deploy is smart enough to compare the remote server with your local project – and only copy the files it needs to.  So if you make a quick few changes to a large project, and then re-publish again – only those files that changed will be copied over.  The files that weren’t updated won’t need to be copied again.  This makes re-deploying/updating a site much faster – especially when there is a lot of static content and large images in the project.

Web Deploy also by default compresses files before it copies them to the Web Deploy service – which shrinks the wire-size and enables faster deployments.


View Entire Article

User Comments

No comments posted yet.

Product Spotlight
Product Spotlight 





Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-03-29 5:30:10 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search