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:
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:
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.