ASP.NET 4 Unleased - p 160 pot

After you complete this final step, you can transfer ASP.NET applications with encrypted configuration files back and forth between the two servers.. In the final section, you also learn

CHAPTER 34 Configuring Applications

Executing this command modifies the ACLs for the SharedKeys key container so that the

ASPNET account has access to the encryption keys

After you complete this final step, you can transfer ASP.NET applications with encrypted

configuration files back and forth between the two servers An application on one server

can read configuration files that were encrypted on the other server

NOTE

As an alternative to using the aspnet_regiis tool, you can transfer encryption keys

with the help of the RsaProtectedConfigurationProvider class The

RsaProtectedConfigurationProvider class contains methods for exporting and

importing keys to and from XML files programmatically

Summary

This chapter was devoted to the topic of configuration In the first section, you were

provided with an overview of the configuration sections used by ASP.NET Framework You

learned how to lock configuration sections to prevent sections from being modified You

also learned how to place configuration sections in external files

Next, we tackled the topic of the Configuration API You learned how to read and modify

configuration files programmatically You also learned how to provision new ASP.NET

applications by creating new virtual directories and configuration files

You learned how to create custom configuration sections and how to create both simple

custom configuration sections and custom configuration sections that contain custom

collections of configuration elements

Finally, we discussed the topic of encryption You learned how to encrypt a configuration

section by using the aspnet_regiis command-line tool You also learned how to encrypt

configuration sections programmatically In the final section, you also learned how to

deploy encrypted configuration files from a development server to a production server

Deploying ASP.NET Web

Applications

Packaging Web Applications Using Web.config

Transformations Deploying Databases One-Click Publishing Web Applications

Summary

Many developers have been in the situation in which

they have spent a tremendous amount of effort building a

web application but when it comes time to deploy it, things

fall apart Some teams don’t spend enough time planning

for deployment, other times the deployment is just

hindered by poor or inadequate technology

This chapter shows you how new features in ASP.NET 4

ease the burden of web application deployment After

reading this chapter, you should quickly and easily deploy

ASP.NET 4 applications to your development, testing,

staging, and production environments—hopefully without

any of the pain and suffering this process caused with

previous versions

Packaging Web Applications

When ASP.NET was first released, one of its most lauded

features was Xcopy deployment This basically referred to

the ability of a developer to copy files from one location to

the other, and the application should work This was a

response to the often complicated web deployment process

of legacy ASP applications

Copying files to deploy a web application is still a benefit,

but today’s web applications have become far more than

just a collection of aspx files and the site’s compiled DLL

file Modern web applications carry a tremendous amount

of “baggage” and modern developers need a way of

bundling all that baggage with an application to deploy it

smoothly and quickly

CHAPTER 35 Deploying ASP.NET Web Applications

Today’s web applications can consist of any or all of the following:

Content (aspx, ascx, images, compiled binaries, media, XML files, and so on)

Databases

Assemblies that need to be in the Global Assembly Cache (GAC)

Registry and Configuration Settings

Security settings (certificates, CAS policy, and such)

IIS Configuration (security, custom error pages, and more)

This is just the tip of the iceberg Any web application of sufficient complexity requires a

large amount of ancillary “stuff.” Up until now, developers have had no real good way of

packaging this stuff in a single, simplified way

Some developers reading this book might have had experience with building web

applica-tions in Java And Java web application developers have long had a facility known as WAR

(Web Archive) files These files are basically ZIP archives that contain (usually) everything

that a particular web site needs to function, including security policy, configuration files,

and bundled content and media

Visual Studio 2010 now gives developers the ability to create such single file bundles

directly from within the IDE (Although it can be done from the command line and from

within MSBuild as well!)

Before you deploy a web application, you’re actually going to need a web application—so

if you want to follow along you can simply create a new ASP.NET Web Application in

Visual Studio 2010 Make sure it uses IIS as the web host server and not Visual Studio; this

can help demonstrate the capability to deploy IIS configuration settings later

After you create the application, right-click the project in Solution Explorer and choose

properties Click the Package/Publish Web vertical tab This displays the screen that

enables you to configure how your application is going to be packaged Figure 35.1 shows

a sample of this screen

A bunch of options are on this screen, but some of the more important ones are listed

here:

Items to Deploy—This enables you to choose whether you just want items

neces-sary to run the application or whether you want source code and debug symbols

deployed as well

Include All Databases—We discuss this option later in the chapter.

Include all IIS Settings—Because the application runs under IIS (remember we

mentioned you should configure your app to run under IIS?) the deployment

bundler can actually grab the IIS settings for your application during the packaging

process These settings will be preserved by the target IIS server upon deployment

To actually build the deployment package, right-click the project in Solution Explorer

and choose the Build Deployment Package option This runs a build step, and you should

see Publish Succeeded at the bottom of your build log Open up the folder you chose as

the package destination, and you should see the ZIP file you built

If you crack open that ZIP file with your favorite ZIP tool or with Windows Explorer, you

can see there’s a Content folder and a few XML files, notably archive.xml (used for the

archive itself), parameters.xml (used for IIS settings, and so on), and systeminfo.xml

(contains a list of installed components)

Next, let’s move to the destination machine (you can do this from your development

workstation as well if you don’t have a staging server handy) and import the application

To do that, open up the IIS Management console (Under Administrative Tools, Internet

Information Services (IIS) Manager), right-click the Default Web Site node, and select

Deploy; then select Import Application After you browse to the location of the ZIP file,

you see an information dialog showing the contents of the deployment package,

includ-ing the content and IIS settinclud-ings You now have the ability to ignore individual bits of

content or IIS settings Under Advanced Settings you also have the option of setting the

Create Deployment Package as a ZIP File—You can choose to build a

deploy-ment package as a single file or as a folder hierarchy In general you probably always

want to use the ZIP file because it is easier to move around between servers A folder

hierarchy enables you to perform file- and folder-level diff comparisons, however

IIS Site/Application Name—You can prespecify the name of the application (or

site) that will be deployed and the physical path for deployment As you see shortly,

the administrator importing this package can override this values if they choose

CHAPTER 35 Deploying ASP.NET Web Applications

WhatIf flag, which enable you to do a mock import (shown in Figure 35.2) The WhatIf

flag is extremely handy when doing new application imports on production servers

When you’re satisfied with what’s on this screen, click Next to continue This brings up

the final confirmation screen shown in Figure 35.3, which enables you to specify the

name of the application, the physical location of the files, and so on After clicking Next,

you see a progress bar; then the application appears configured and ready to run in the IIS

Management console

This is an absolutely priceless utility to have Now developers can create deployment

pack-ages and give them to the administrators who have secured control over QA, Staging, and

Production environments All these people have to do is import the deployment package

and all the files, content, prerequisites, and configuration necessary for that application

will be put where they belong

Using Web.config Transformations

So far we’ve seen that with Visual Studio 2010 we can create new web deployment

pack-ages that drastically simplify the deployment of applications to interim environments

such as QA and Staging, but what about the configuration? Application settings,

connec-tion strings, web service endpoints, and hundreds of other pieces of configuraconnec-tion all

typi-cally vary depending on whether the application is running on a developer workstation,

in QA, in Staging, or in Production So how do we take advantage of the great web

deploy-ment tools but still have varying configuration files?

Before Visual Studio 2010, we would write custom build scripts that would replace our

Web.config files with custom files specific to certain environments Now, having a

Web.config file specialized for specific build targets is actually built into Visual Studio

For each of your build configurations (by default VS2010 comes with Debug and Release,

but you can create as many as you like), you can have a Web.config file This file isn’t a

complete copy of the file but is actually a list of transformations you want to make to the

original This is actually a smart strategy because the bulk of the config file typically stays

the same across environments with small changes to things such as service endpoints,

connection strings, and app settings

To see this in action, let’s add a build configuration to the empty ASP.NET project we

deployed in the previous section To do this, right-click the solution in Solution Explorer

and bring up the Configuration Manager (see Figure 35.4) Click the drop-down arrow next

to the configuration for the web application (probably says Debug at the moment) and

select New Call the new configuration Staging, and base it on the Release configuration

Open up the main Web.config file and add a new app setting as shown here:

<appSettings>

<add key=”Environment” value=”DevWorkstation”/>

</appSettings>

Now for the fun part—creating the transformation Double-click the Web.staging.config

file to bring it up in the IDE Add the following code below the commented out sample

involving a connection string:

<appSettings>

<add key=”Environment” value=”Staging”

xdt:Transform=”SetAttributes” xdt:Locator=”Match(key)”/>

</appSettings>

The full syntax of the transformation language would be too much to include in this

chapter; however, a link to detailed MSDN documentation directly is in the sample config

file, http://go.microsoft.com/fwlink/?LinkId=125889 The code we just put into the file

searches the root Web.config for a key matching the string “Environment” and replace the

value with the one from the staging file If we then create a web deployment package with

Staging being our active configuration, we end up with an appSettings element in the

deployed Web.config that looks like this:

<appSettings>

<add key=”Environment” value=”Staging” />

</appSettings>

The power we get from the combination of transformable configuration files on a

per-build-configuration basis and the web deployment packages is incredible We can now

CHAPTER 35 Deploying ASP.NET Web Applications

After you have a staging configuration created, you can right-click the Web.config file and

select Add config transforms, as shown in Figure 35.5 This is the only way to create the

Web.config transformation files If you manually create a Web.staging.config file without

going through this menu item, it won’t compile properly and will not properly transform

your Web.config file

create individual package files that are targeted at a specific environment and have

confi-dence that the app will contain all its content, binaries, prerequisites, and configuration

suited for that environment

Deploying Databases

Although it’s certainly a huge productivity increase and a time and stress saver, it sure

would be great if we could correlate our database migrations with our application

deployments

The folks at Microsoft have thought of this as well There is a Package/Publish SQL tab on

the project properties page now This enables you to create a list of database deployments

in a grid For each of those deployments, you can define a source database and a

destina-tion database You can also choose whether the deployment includes schema only, data

only, or both Also keep in mind that all this information is also on a per-configuration

basis, so the list of databases and their source/target pairs will be different depending on

whether you create a production deployment or staging deployment

Figure 35.6 shows a screenshot of this new Publish/Package SQL screen

CHAPTER 35 Deploying ASP.NET Web Applications

In this scenario, we have a web application that we built called Zombie Killa, a social

network for zombie killers At the top of the figure you can see a grid where we can define

all the databases that we want to include in the deployment, so we’re not limited to just

one database Also, keep in mind that these databases are independent of any database

projects you might have in your solution

For each of the databases in the grid, we can then configure the options shown in the

lower half of Figure 35.6 We can define the connection string for the source database and

the connection string for the destination database We can also configure what is copied

from one to the other: schema, data, or both Finally, we can also add custom SQL scripts

that do specific migration-related tasks because even the best databases have thorns in

them that create bumps or stalls for migration processes

Now when we build a deployment package, it contain all the information necessary to

ensure that when the web application is fully deployed in the target environment; all its

required databases will be available as well, containing exactly the data and schema that we

want them to have

One-Click Publishing Web Applications

In the previous section, we gave you an overview of how to create portable, self-contained

web deployment packages These packages can be copied to servers and installed on those

servers by developers or administrators and can contain all an application’s prerequisites,

even database migration scripts

Microsoft actually took this facility one step further Through Visual Studio 2010, we can

actually create publishing profiles that we can use to publish a web application directly

from the IDE This comes in extremely handy when we use VS2010 to work on a web

application that we’re deploying to a hosting company

NOTE

When we talk about hosting company here, we’re specifically talking about web hosting

companies that provide a remote IIS with the MSDeploy service available for secure

deployment The type of deployment we’re talking about in this chapter is unrelated to

Windows Azure and deployment in the cloud

Visual Studio 2010 enables us to have up to 50 different publishing profiles, which is more

than enough room to allow for one-clicking publishing to a local IIS, a development

envi-ronment, staging, QA, production, remotely hosted sites, and everything in between

One-Click publication is just a layer on top of the web deployment configuration you saw

in the previous section It takes all the information from the Package/Publish Web and the

Package/Publish SQL property pages and performs the packaging process and the remote

deployment in one step

As mentioned, you can deploy to a local IIS or a remote one within your own

organiza-tion or a remote one hosted by a third party The only requirement is that the web

deployment tool be installed on the destination server If you install Visual Studio 2010

on top of a machine with IIS7, you already have the web deployment tool installed If you

don’t have it installed (version 1.1, at the time this book was written), you can get it from

http://www.iis.net/expand/WebDeploy This site has a link that you can use to install the

tool using the Web Platform Installer and a wealth of documentation and videos to give

you more information on the web deployment tool than is in scope for this book

If you have nightmarish flashbacks of deployment using FrontPage Extensions and twitch

at the memory of the difficulties and heartburn caused by those days, you can rest easy—

deployment with MSDeploy is, nothing like deployment using FrontPage extensions

Summary

ASP.NET 4 brings with it quite a few new features to make the act of developing websites

easier, more reliable, even faster and more scalable However, as an added bonus, we now

also have the ability to create web deployment packages that bundle up our web

To trigger the one-click publish process, you can right-click the project and choose Publish

(yes, we know that’s actually two clicks), or you can push up a single button in the

Publish toolbar that defaults to a position at the top of your IDE Figure 35.7 shows what

happens when you click this button