Tải bản đầy đủ
Objective 5.3: Configure a web application for deployment

Objective 5.3: Configure a web application for deployment

Tải bản đầy đủ

This objective covers how to:
■■

Switch from production/release mode to debug mode

■■

Transform web.config by XSLT

■■

Use SetParameters to set up an IIS app pool

■■

Configure WCF endpoints, bindings, and behaviors

■■

Configure Windows Azure configuration settings

Switching from production/release mode to debug
When building your projects, you use a build configuration. Two configurations are declared
by default: release and debug. For the exam, you should know the differences between these
configurations and the scenarios in which they should be used.
In release mode, your code is optimized for running as fast as possible. Of course, this is
something that you want to use when your code is deployed to your production server.
However, release mode is not handy when you are debugging your applications. When
you compile an application in debug mode, extra instructions are added to your compiled
code. This ensures that debugging is supported, and that you can easily step through your
code with a debugger.
In addition to your build configuration, there is also a debug switch in your web.config file:






By setting this value to false, you turn debug mode off.
In Visual Studio, you also have an option to select which debuggers you want to load when
debugging your project, as you can see in Figure 5-9.

384

CHAPTER 5

Deploying web applications and services

FIGURE 5-9  Selecting available debuggers for your ASP.NET application

The enabled debuggers work only when your code is compiled with debugging
information.

Transforming web.config by XSLT
In your web.config file, you store all kinds of settings such as connection strings, WCF configurations, and custom appSettings. While they run on your development PC, you have set
them to values that make sense for your local environment.
When you deploy your application, you have to change those values to configure your
application correctly. Doing this manually takes time and can lead to errors. One way to deal
with this problem is to use the web.config transformation syntax. When using this, you define
an XML file that describes the changes that you want to apply to your web.config file. Web.
config transformations are popular, and you can expect questions on how to use them on the
exam.
When you create a new ASP.NET Model-View-Controller (MVC) application, transformation
files for the debug and release configuration are created (see Figure 5-10).



Objective 5.3: Configure a web application for deployment

CHAPTER 5

385

FIGURE 5-10  The web.config file with two nested transformation files

Web.config transformations work with a special XML-Document-Transform syntax. Here
is an example of a transformation file that changes your connection string and configures
customErrors:



connectionString="value for the deployed Web.config file"
xdt:Transform="SetAttributes" xdt:Locator="Match(name)"/>


mode="RemoteOnly" xdt:Transform="Replace">





You start with specifying the correct namespace for your transformation file. After
that, you can place the elements that you want to change. By using the xdt:Transform and
xdt:Locator attributes, you configure how the element should be located and what should
happen when it is found.
In the case of the customErrors element, you completely replace it with a new value on
transformation. The connection string is used only to change the actual value of the connection string.

386

CHAPTER 5

Deploying web applications and services

For your locator attribute, you can use the following values:
■■

■■

■■

Condition specifies an XPath expression that is appended to the current element’s
XPath expression.
Match selects the element or elements that have a matching value for the specified
attribute or attributes.
XPath specifies an absolute XPath expression that is applied to the development
web.config file.

For the transform attribute, you can use the following:
■■

Insert

■■

InsertBefore

■■

InsertAfter

■■

Remove

■■

RemoveAll

■■

RemoveAttributes

■■

SetAttributes

MORE INFO  WEB.CONFIG TRANSFORMATION SYNTAX

For examples of how to use web.config transformation, see http://msdn.microsoft.com/
en-us/library/dd465326.aspx.

Using SetParameters to set up an IIS app pool
Web.config transformation is being done at compile time. If you know beforehand to which
environment you will publish, web.config transformation is a great tool. The transformation
process, however, is not something that you can change at installation time.
When using Web Deploy packages, you have another option. If you want to create one
Web Deploy package and then deploy it to multiple locations, you can use parameterization.
When creating a Web Deploy package, a couple of files are created for you:
■■
■■

■■

[project name].zip is the Web Deployment package.
[project name].deploy.cmd offers a convenient way of deploying your application from
the command line.
[project name].SetParameters.xml provides a set of values that MSDeploy.exe uses to
deploy your package.

The SetParameters file is dynamically generated for you. It’s based on the settings that you
specified in your project settings and other configuration settings files in your project (such
as web.config). For example, if you have a connection string in your web.config file, it will be
picked up, and a parameter for your connection string will be added to the SetParameters.xml
file.


Objective 5.3: Configure a web application for deployment

CHAPTER 5

387

You can configure extra values for parameterization by passing a Parameters.xml file to
Web Deploy when creating the package. In this file, you indicate the file that you want to
parameterize, what variable you want to change, and what the default value is. These values
will later be used by Web Deploy to ask the user for input.
When you import a package through the IIS Manager, you get a dialog box that asks you
for the values for all parameters you specified. When doing it from the command prompt,
you use the SetParameters.xml file.
In most scenarios, you won’t need any custom parameterization if you use Visual Studio.
However, in a couple of scenarios, it can be useful to add custom parameters to your deployment package like custom appSettings, WCF service configuration at install time, or a web
package that’s going to be installed by end users in several different scenarios.
In Visual Studio, you can add the Parameters.xml file to the root of your web project. Here
you see a typical example that enables the user to modify an appSetting:







The parameter element has a few attributes:
■■

name  The name you specify is shown in IIS Manager when you import the package.

■■

description  The description you use is also shown in IIS Manager.

■■

■■
■■

■■

defaultValue  This value is preloaded in the text box in IIS Manager so a user can just
accept this value when importing your package.
scope  A regular expression that shows the files to which the parameter applies.
match  In the case of an XmlFile, an XPath expression that selects the XML node that
you want to change.
kind  Specifies the kind of resource the parameter will be applied to (such as XmlFile
or TextFile).

Say you have the following endpoint configuration for WCF in the system.ServiceModel
section of your web.config file:

bindingConfiguration="BasicHttpBinding_MyService"
contract="ServiceReference.IMyService"
name="BasicHttpBinding_MyService"/>


388

CHAPTER 5

Deploying web applications and services

Of course, the localhost address is something you want to be able to change during an
installation. To do this, you can add the following to your Parameters.xml file:
description="Please provide the Endpoint address for MyService that this
application needs to call" defaultValue="http://localhost:8080/MyService.svc"
tags="">
match="//system.serviceModel/client/endpoint/@address" />


If you now run the Publish process from Visual Studio, the SetParameters.xml file
contains an extra entry for your WCF My Endpoint Address with a default value of
http://localhost:8080/MyService.svc.
Of course, you can’t use this to only change the address. You can also use it to configure
your bindings and behaviors. Every XML element of your web.config file (or other files) can be
parameterized.
MORE INFO  USING PARAMETERS

For a complete description of how to use parameters in more complex scenarios, see
http://www.iis.net/learn/develop/windows-web-application-gallery/reference-for-the-webapplication-package.

If you’re not using Visual Studio but instead the command prompt, you can use the
declare​ParamFile and setParamFile options to specify a Parameters.xml and SetParameters.
xml file:
msdeploy.exe -verb:sync -source:apphostconfig="default web site/application"
-dest:archivedir="C:\packages\application" -declareParamFile="C:\source\application\
deployment\declareParamsFile.xml"
msdeploy.exe -verb:sync -dest:apphostconfig="default web site/application"
-source:archivedir="C:\packages\application" -setParamFile="C:\source\application\
deployment\setParamsFile.xml"

Changing the SetParameters.xml file by hand each time is not what you want if you run in
an automated environment. If you want to automate changing the values for setParameters in
your build process, you can use something called XmlPoke. XmlPoke is an MSBuild task that
you can run during your build process.
MORE INFO XMLPOKE

For an example of how to use XmlPoke, see http://www.asp.net/web-forms/tutorials/
deployment/web-deployment-in-the-enterprise/configuring-parameters-for-web-packagedeployment.



Objective 5.3: Configure a web application for deployment

CHAPTER 5

389

EXAM TIP

Make sure that you understand both web.config transformations and the use of parameters. Remember that transformations are done at compile time, and parameter values are
set during deployment.

Configuring Windows Azure configuration settings
A Windows Azure cloud project has two configuration files:
■■

ServiceConfiguration.Cloud.cscfg

■■

ServiceConfiguration.Local.cscfg

By using these files, you can configure your cloud service. The local file contains values that
will be used by your Windows Azure emulator. The cloud file will be used when deploying
your application to Windows Azure.
Inside your configuration file, you can specify settings such as the number of role instances
to deploy for each role, the values of any configuration settings, and the thumbprints for
certificates associated with a role.
You can also specify the virtual hard disk when you are working with a virtual machine. If
your service is part of a virtual network, you can configure your virtual network through this
file.
MORE INFO  CONFIGURING THE GUEST OS

Objective 5.2, “Choose a deployment strategy for Windows Azure web applications,” shows
you how to use the service configuration to configure the Windows Azure Guest OS you
want your roles to run on.

If you create a new cloud project with a web and a worker role, you get the following
configuration file:

xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration"
osFamily="3" osVersion="*" schemaVersion="2013-03.2.0">



value="UseDevelopmentStorage=true" />





value="UseDevelopmentStorage=true" />

390

CHAPTER 5

Deploying web applications and services





The role element specifies the name of your role. It can also specify a vmName that it uses
as the Domain Name System (DNS) name of your Virtual Machine (VM).
Nested in your role element, you can configure the number of instances that your role
should be deployed to. Your ConfigurationSettings is a collection of name value pairs. In
the configuration generated by Visual Studio, you see one entry that describes where the
diagnostic data should be stored. This is a value you should change when doing an actual
deployment.
Another element you can add is the Certificate element:

thumbprintAlgorithm="" />


Your Certificate elements describe the thumbprint and the algorithm associated with a
certificate.
You can have one other element: OsImage:


This specifies the name of a Virtual Hard Disk (VHD) image for a VM role.
Next to the roles configuration, you can also have NetworkConfiguration. This section
specifies Virtual Network and DNS values. This element is optional. An example of the schema
of the NetworkConfiguration might be the following:

















This element describes the network configuration into which your service will be deployed.



Objective 5.3: Configure a web application for deployment

CHAPTER 5

391

MORE INFO  CONFIGURING A VIRTUAL NETWORK

For more information on using the NetworkConfiguration element to configure a virtual
network, see http://msdn.microsoft.com/en-us/library/windowsazure/jj156091.aspx.

Thought experiment 
Preparing for deployment
In this thought experiment, apply what you’ve learned about this objective. You can
find answers to these questions in the “Answers” section at the end of this chapter.
You are creating a complex web application that will be deployed to multiple,
on-premises servers. You are working with development, testing, acceptance, and
production environments; and you want to automate your deployment as much as
possible.
With this in mind, answer the following questions:

1. Which configuration do you want to release to each of your different
environments?

2. Do you want to use Web.config transformations or parameters with Web Deploy
for your deployment pipeline?

Objective summary
■■

■■

■■

■■

A projects is built with a configuration. You can use a debug and release configuration
or create custom configurations.
Web.config transformations are a way of transforming your web.config file by using
a special syntax. This way, you can easily change values for things such as connection
strings or WCF settings.
Web Deploy can use parameters to specify which values in your configuration can
be changed during installation. By using a SetParameters.xml file, you can define the
values you want to use.
Windows Azure is configured by using a ServiceConfiguration.cscfg file. There are two
files: one for your local environment and one for the cloud. Using these files, you can
configure your roles and network configuration.

Objective review
Answer the following questions to test your knowledge of the information in this objective.
You can find the answers to these questions and explanations of why each answer choice is
correct or incorrect in the “Answers” section at the end of this chapter.
392

CHAPTER 5

Deploying web applications and services

1. You want to deploy your ASP.NET MVC application to your own web server for produc-

tion. Which steps do you take? (Choose all that apply.)
A. Change the debug attribute of the web.config to false.
B. Build a release configuration.
C. Disable the ASP.NET debugger in the Debuggers section of your project

properties.
D. Build a debug configuration.
2. You want to remove your debug element from the web.config file by using web.config

transformations. Which syntax do you use?
A.
B.
debug=’true’)” />
C.
xdt:Locator=”Match(name)” />
D.
3. You are using parameters for your Web Deploy. You want to automate the creation of

the SetParameters file and make sure that it has the correct values. What do you use?
A. XmlPoke with MSDeploy.
B. MSDeploy with the setParamFile attribute.
C. XmlPoke with MSBuild.
D. This is not possible. You need to edit the SetParameters file manually.

Objective 5.4: Manage packages by using NuGet
Today, there are a lot of libraries. Some help you build web applications: jQuery, Modernizr,
and Knockout. Others focus on architectural issues: dependency injection tools such as Ninject or StructureMap.
When building your applications, it pays to know which libraries are out there so you can
save time by reusing code that’s already developed and well tested. But searching the web for
available libraries, looking for a download location, and adding them to your project can be
time-consuming, especially when the library gets regular updates and you have to repeat the
whole process.
The same is true for internal libraries. Maybe you have some code that you want to use
in several of your projects. Keeping the libraries up to date and making sure that everyone
knows they exist and knows how to use them can be difficult tasks.



Objective 5.4: Manage packages by using NuGet

CHAPTER 5

393

You are expected to know how to manage packages with NuGet for the exam. You should
also be able to define the necessary steps for creating your own NuGet feed. This section
explains how NuGet as a package manager manages libraries internally and externally, and
ensures that you can consume them with minimal effort.

This objective covers how to:
■■

Install and update an existing NuGet package

■■

Create and configure a NuGet package

■■

Connect to a local repository cache

■■

Set up your own package repository

Installing and updating an existing NuGet package
At http://nuget.org, you can find the NuGet gallery. This gallery contains all packages that are
currently available. At the time of writing, there are tens of thousands of packages that are
downloaded millions of times.
As you can see, this offers you a wealth of potentially useful packages that you can use
in your own projects. Almost all popular frameworks, such as jQuery, Json.NET, or the Entity
Framework, are available from NuGet. If the exam asks you to reference a popular library, you
should immediately think of NuGet.
Starting with Visual Studio 2012, the project templates are based on NuGet packages.
Instead of distributing one fixed version of a library with Visual Studio, Microsoft chose to use
the packages available from NuGet in its templates.
If you create a new ASP.NET MVC project based on the Internet template in Visual Studio
2012, you get a file called packages.config in the root of your project. You can see the contents of this file in Listing 5-1.
LISTING 5-1  packages.config




targetFramework="net45" />
/>
/>
targetFramework="net45" />




394

CHAPTER 5

Deploying web applications and services