第 143 页

Deployment Tool

.

Managing configuration files for multiple deployment environments

.

Keeping machines up to date with the Web Platform Installer

.

Extending the Web Platform Installer to include your own

applications

In the previous chapter you saw how to deploy your Windows application using either an

installer or ClickOnce. But how do you go about deploying web applications? This chapter

walks you through deploying Web Site and Web Application projects. It also covers packaging

web applications for remote deployment with the new Web Deployment Tool and integrating

with the Web Platform Installer.

One of the most important aspects of building your application is to think about how you will

package it so that it can be deployed. Though a large proportion of web applications are only

for internal release, where a simple copy script might be sufficient, if you do want to make

your web application available for others to purchase and use, you really need to focus on

making the deployment process as simple as possible.

984 .

chaPter 49 Web ApplicATion deploymenT

After the release of Visual Studio 2005, Microsoft released Web Deployment

Projects as a more advanced way of managing the deployment of Web Site and

Web Application projects. When Visual Studio 2008 was released, these projects

were updated but not included in the final release. At the time of writing,

Microsoft has not announced any plans to include Web Deployment Projects in

Visual Studio 2010.

web site dePloyMent

Web projects created with Visual Studio 2010 fall into two broad categories: Web Application

projects and Web Site projects. This section demonstrates tools that are specifically for deploying

and maintaining Web Site projects.

Publish web site

The simplest way to deploy a web site from Visual Studio 2010 is to publish it via the Publish

Web Site item on the Build menu. Selecting this option presents you with the dialog shown in

Figure 49-1. It has only a few basic options that allow you to publish debugging information, allow

in-place updating of your web site, and enforce different naming policies and security requirements.

Usually you will simply use the Target Location box to specify the location that you want to publish

to. This location can be a local instance of IIS, an FTP site, elsewhere on the file system, or a remote

instance of IIS. Clicking the ellipsis button next to the Target Location textbox in Figure 49-1

brings up a dialog to specify the details of where you want to publish to, as shown in Figure 49-2.

fiGure 49-1 fiGure 49-2

Web site Deployment .

985

Here we are publishing to a private FTP account, and if this is the first time we

are publishing this site we may have to define this folder as an IIS application in

order for the web site to function.

copy web site

Once a web site has been published, it is important that you have some way of updating it. One

option is to go through the process of publishing your web site again. However, this will publish the

entire web site, even if only a single file needs to be updated. An alternative is to use the Copy Web

Site tool, shown in Figure 49-3, to synchronize files between your development project and the

web site. You can access this tool from the right-click context menu in the Solution Explorer,

or via the web site menu.

fiGure 49-3

To view the existing files on the remote web site, you need to either select a recent connection from

the drop - down list or click the Connect button. This will open a dialog similar to Figure 49 - 2, where

you can specify how to connect to the remote web site. Once you have connected you can see which

files are out of sync. You can then use the right and left arrows to move files between your local

project and the remote web site.

986 .

chaPter 49 Web ApplicATion deploymenT

web aPPlication dePloyMent

Web application projects are quite different from Web Site projects and come with a different

set of tools for deployment. Visual Studio 2010 introduces the capability to deploy with the new

Web Deployment Tool, which is used to easily import and export IIS applications along with

their dependencies — such as IIS meta-data and databases — from the command line, IIS 7.0

management console, Powershell cmdlets, or directly from Visual Studio itself. It also provides

the ability to manage several versions of configuration data for different environments in a clean

manner without duplication.

Publishing a web application

The quickest way to deploy a Web Application

project is to simply publish it directly from Visual

Studio. Select the Publish item from the right-click

context menu in Solution Explorer to display the

Publish Web dialog shown in 49-4. If this is the first

time you have run the Publish Web dialog, Publish

Profile will be a textbox instead of a drop-down

enabling you to give the profile a meaningful name.

Each time you do a deployment you do so against

a particular profile, which encapsulates the target

environment settings. A Web Application project can

maintain a collection of profiles, which allows you

deploy the one web application to a number of target

environments and keep the settings for each separate.

Four options for Publish Method determine what

you see in the lower part of the dialog window: Web

Deploy FTP, File System, and Front-Page Server

Extensions (FPSE). The File System and Front-

Page Server Extensions options both allow you to

enter the target location for the web application to

be published. The FTP option offers the same but

also allows you to enter FTP credentials. Each of

these provides a cut down version of Figure 49-2

if you click the ellipsis on Target Location. The only other settings for these choices is whether to

simply replace any files in the target location or clear all of the files from the target location before

deployment.

The final publishing method option is Web Deploy MSDeploy.exe, also known as the Web

Deployment Tool, is designed to help administrators and developers more easily package and deploy

web application projects. It does this by packaging all of the necessary files for your application

along with all of the required meta-data to install and configure it into a single zip file. This zip

file can then be installed via the IIS7.0 interface, the command line, Powershell cmdlets, or directly

from Visual Studio itself.

fiGure 49-4

To deploy directly to a server that is running MSDeploy, you will need:

A service reference where MSDeploy w . ill be listening

. A site and application name used to identify the remote application

. A username and password for the remote instance of MSDeploy

All of this information will be provided by your server administrator or hosting provider.

Once you have published your web application successfully at least once, the Web One Click Publish

toolbar will become available. This toolbar, shown in Figure 49 - 5, allows you to select a publishing

profi le and click the Publish button to instantly publish your web

application. If you don ’ t see the toolbar, you can enable it by selecting

View . Toolbars . Web One Click Publish from the main menu.

If you start the Publish process from the main menu or from the project

right - click context menu, you will get the option to examine the profi le

properties before the application is deployed. When you use the Web One Click

Publish toolbar, however, the deployment starts immediately.

fiGure 49 - 5

Packaging a web application

Even if you do not have direct access to the target environment, you can still create packages that can

be managed by the Web Deployment Tool. This is as simple as selecting Create Package from the

right - click context menu of the Web Application project in the Solution Explorer window.

By default, this generates a zip fi le along with some support material in the obj\Debug\Package\

folder. The support material includes a sample .cmd fi le along with a parameters fi le, which can be

used to install the package from the command line on the target server.

These packages are precisely what get deployed to a remote server during an

MSDeploy Publish.

Confi guring Web application Packages

One important aspect of deploying and packaging web applications is confi guring what gets

deployed. You can reach the Package/Publish settings tab pictured in Figure 49 - 6 from the normal

project properties pages, or by selecting the Package/Publish Settings item in the right - click context

menu of the project in the Solution Explorer window.

Web application Deployment . 987

988

.

chaPter 49 Web ApplicATion deploymenT

fiGure 49-6

The first option to configure is which files to actually deploy. The three options are as follows:

.

Only files needed to run the application will include only the files that are actually necessary

to running the application. This can exclude files with a build action of None. This is

the most exclusive option and is the default.

.

All files in this project will include any file that appears as a part of the project in the

Solution Explorer window.

.

All files in this project folder will include any file that is found in the project folder even if it

is not a part of the project. This is the least restrictive option.

You also have options to exclude generated debug files and files in the App_Data folder. To deploy

databases you should use the Package/Publish SQL options, which are discussed in the next section.

A Web Deployment Package is also able to copy IIS meta-data, but only if your project is being

developed in IIS. To configure this, go to the Web properties page and change the Servers option to

Use Local IIS Web Server.

Finally, you can opt to provide a location for the deployment package to be created and a

web site/application name to apply to the package when it is deployed to an IIS server.

Packaging sQl server Data

One common problem when deploying web applications is that they frequently rely on a database

server to store data and so the deployment process has to find a way to manage the deployment of

a database schema, and potentially data as well. Web Deployment Packages allow you to specify

database scripts to set up or update your databases, and the Web Deployment Tool manages the

process of running these scripts against a database server during the deployment process.

Web application Deployment.

989

To add a database to your deployment package, use the Package/Publish SQL property page for

the web project shown in Figure 49-7. Use the Add and Remove buttons on the right-hand side to

maintain a list of connections that are to be deployed. If you already have a set of connection

strings in the web.config file, you can import them directly into this list using the Import from

Web.Config button provided. You can also use the checkboxes to decide whether or not to include

each connection string in the deployment.

fiGure 49-7

When you have a connection string highlighted in the top section, the bottom section displays

deployment details relating to that connection string. The first option allows you to provide a

different connection string for the deployment package.

The next option allows you pull a schema and/or data from an existing database while creating the

deployment package. To do this, you need to simply provide a connection string and select whether

schema, data, or both should be deployed. In addition to these automatically generated database

scripts, you can add your own database scripts to the deployment. This can be useful if you are

using a tool that produces change scripts for your database.

When you use Visual Studio to extract schema information or data from an

existing SQL Server, it generates scripts suitable for deploying a brand new

database. To update an existing database, you need to create your own scripts

and add them to the package.

web config transformations

One other problem that many projects face is how to maintain different versions of application

configuration between different environments. This problem is commonly handled by keeping

several copies of the web.config file around — one for each environment — and then remembering

990 .

chaPter 49 Web ApplicATion deploymenT

to rename the correct version for the target environment every time the application is deployed. Even

if you make this a part of your build process, this can be problematic because any change to the

web.config file potentially needs to be replicated to each of the other environment-specific configuration

files. Visual Studio 2010 introduces a new capability called Web.config Transformation, which allows

you to have a single configuration file and then specify only the differences for each environment.

When a web application project is first created it includes a web.config file along with two config

transforms, one for each build configuration: Debug and Release. Each transform is associated

with a single configuration and appears under the web.config file in the Solution Explorer

(see Figure 49-8). To create your own configuration, select Configuration Manager from the

Configuration drop-down menu and then select New from the Active solution

configuration drop-down. Enter a name for your new configuration and

optionally select which previous configuration it should copy its values from.

fiGure 49-8

Once you have a new configuration, you can add a new config transform by

selecting Add Config Transforms from the right-click context menu of the web.config file in

Solution Explorer. This automatically adds any transforms that were missing from the solution’s

Configuration collection.

The configuration transform file is a standard configuration file, but it adds a new XML namespace

for specifying transformations. This namespace contains two attributes, Transform and Locator,

which can be added to any element in the configuration file. Transform is used to specify a change