Microsoft ASP.NET 4 Hosting Deployment Guide - Download Center ...

farmacridInternet and Web Development

Feb 2, 2013 (4 years and 7 months ago)

302 views



Microsoft ASP.NET

4


Hosting Deployment Guide


Published:
May

2010


Abstract

This white
paper provides an overview of the features and benefits of Microsoft
®

ASP.NET
4

for Web
hosting

and provides information about how to configure ASP.NET and IIS in shared hosting
environments
. Hosters
who
offer
ASP.NET
hosting
can

use the setup and configuration
recommendations to integrate ASP.NET
into

their hosting solution.
H
osters who have not ye
t
implemented ASP.NET
can

evaluate
the
requirements for implementing ASP.NET
4

in

their hosting
environment
s
.







The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of

the date
of
publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on

the
part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

Thi
s w
hite
paper is for informational purposes only. MICROSOFT

MAKES NO WARRANTIES, EXPRESS,
IMPLIED
,

OR STATUTORY
,
AS TO THE INFORMATION IN THIS
DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rig
hts under copyright, no part of this
document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form or by any means (ele
ctronic,
mechanical, photocopying, recording, or otherwise), or for any purpose, without the e
xpress written permission of Microsoft
Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subje
ct matter in
this document. Except as expressly provided in any written license

agreement from Microsoft, the furnishing of this document does not
give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2010

Microsoft Corporation. All rights reserved.

Unless otherwise noted, t
he example
companies, organizations, products, domain names, e
-
mail addresses, logos, people, places, and
events depicted herein are fictitious. No association with any real company, organization, product, domain name, e
-
mail address, logo,
person, place, or event is

intended or should be inferred.

Microsoft,
MSDN, Visual Web Developer,
Windows,
and
Windows Server,

are either registered trademarks or trademarks of Microsoft
Corporation in the United States and/or other countries.

The names of actual companies and prod
ucts mentioned herein may be the trademarks of their respective owners.



Table of Contents

Overview

................................
................................
................................
................................

1

ASP.NET Versions

................................
................................
................................
..................

1

Trust Levels and ASP.NET Features

................................
................................
............................

2

Additional Resources

................................
................................
................................
.............

3

Trust Level Recommendations for Hosters

................................
................................
................

3

Customizing Trust Level Policy

................................
................................
................................

3

Locking the Trust Level

................................
................................
................................
..........

5

Setting Multiple Trust Levels for Applications

................................
................................
............

5

Providers in
ASP.NET

................................
................................
................................
................

6

Configuring a Database for Use with ASP.NET Providers

................................
.............................

7

Frequently Asked Questions

................................
................................
................................
...

7

Running Multiple Versions of ASP.NET T
ogether

................................
................................
...........

7

Backward Compatibility

................................
................................
................................
..........

7

Running ASP.NET Side
-
by
-
Side

................................
................................
...............................

7

ASP.NET IIS Registration Tool

................................
................................
................................
.

8

Additional Resources

................................
................................
................................
.............

8

SMTP Configuration

................................
................................
................................
..................

8

SMTP Configuration Example

................................
................................
................................
..

9

ASP.NET Configuration API

................................
................................
................................
........

9

Addi
tional Resources

................................
................................
................................
............
10

WebPermission in Medium Trust

................................
................................
...............................
10

Enabling defaultProxy

................................
................................
................................
...........
11

Enabling WebPermission in a Custom Trust Level

................................
................................
.....
12

WebPermission in High Trust

................................
................................
................................
....
12

Code Access Security in ASP.NET 4

................................
................................
...........................
12

Changes to the ASP.NET 4 Medium Trust Configuration File

................................
.......................
13

Reverting ASP.NET 4 to the Legacy CAS Mode

................................
................................
.........
13

Configuring Content to Serve from a Remote File Serv
er

................................
...........................
13

Common Location for Microsoft AJAX Library

................................
................................
..............
14

Hosting Scenarios and Recommendations

................................
................................
..................
14

Trust Levels for a Shared Hosting
Environment

................................
................................
........
14

Hosting and Isolating Multiple Applications

................................
................................
..............
14

Isolating by Application Pool

................................
................................
................................
..
15

Hosting a WCF Service in ASP.NET

................................
................................
.........................
15

Using ASP.NET in a Web Farm

................................
................................
...............................
16

Making Sure That Application State Will Be Maintained in a Web Farm

................................
........
16

Features That Affect Hosters

................................
................................
................................
....
17

Access Databases: Using OLE

DB and ODBC Providers in Medium Trust

................................
....
17

Application Domain Resource Monitoring

................................
................................
..............
17

Performance
Benefits in ASP.NET 2.0 and Later

................................
................................
..........
17

Session State Compression

................................
................................
................................
...
17




WOW64 Compatibility: Running 32
-
bit Applications on a 64
-
bit Server

................................
.......
18

Deploying ASP.NET Step
-
by
-
Step

................................
................................
..............................
18

Additional Resources

................................
................................
................................
............
20



1


Overview

ASP.NET is a powerful set of tools for building dynamic, high
-
performance, data
-
driven Web
applications
.

With ASP.NET, customers can quickly cr
eate Web pages and applications
with rich
f
eatures such as membership, personalization, and themes
that
provide system
-
level functionality that
would normally require extensive developer coding. In addition, Microsoft
Visual Web Developer


20
10

Express
, which is available
as a free downl
oad
, provides
everything
that developers need
to
easily design, build
,

and deploy
great
, dynamic Web applications
.

ASP.NET also provides benefits for hosted environments. For example, ASP.NET includes support for
shutting down inactive applications and fo
r locking down rogue applications. Hosters can also
configure health monitoring to set thresholds and severity levels for monitoring the health of ASP.NET
-
based applications
.

Discrete feature throttling
lets

server administrators dynamically add and remov
e feature support for
applications within individual customer applications.
In addition,

Starter Kits can be offered separately
or easily integrated in a site, providing compelling features for end
-
user customers.

This
white
paper
also
provides information

about how to conf
igure ASP.NET and IIS in shared
hosting
environments. This includes any environment



from a single server computer to a Web farm



w
here multiple discrete users will be running Web sites.

ASP.NET Versions

ASP.NET is part of the .NET Fram
ework.
The .NET Framework was released initial
l
y as version 1.0
and

was upgraded with
ver
s
ion 1.1, followed by
version 2.0
,

version 3.0
,

and version
3.5. Although
ASP.NET does not have version numbers

that are independent of the .NET Framework
, for
convenience this
white
paper uses the common convention of referring to ASP.NET 2.0, ASP.NET 3.0,
ASP.NET 4,
and so on.

The version numbering for the .NET Framework (and
by extension
for ASP.NET) can cause some
confusion. Versions 3.0 and 3.5 of the
.NET Framework
are
not complete replacements for 2.0.
Instead, these releases added features to the core
.NET Framework
2.0 functionality, which
remains

almost unchanged.
Fundamentally, the .NET Framework comes in only
three

versions: ver
sion 1.1,
version
2.0
, and version 4
.
Therefore, i
nformation about versions 3.0 or 3.5 of the
.NET F
ramework or
of ASP.NET refer
s

to new features
that have been
added since the 2.0 release
, or to the small number
of changes
that have been
made to core 2.0 functionality.


Th
e
Windows Server
®

2003
operating system
comes with the .NET Framework
version 1.1
installed.
The
Windows Server

2008 operating system
comes with
the .NET
Framework version 3.0 installed,
which

means that Windows Server 2008 comes with the .NET Framework ve
rsion 2.0 installed plus the
new features that
were added for the 3.0 release.

For both versions of Windows Server, later versions
of the .NET Framework can be downloaded and installed separately. For
more
information, see the
.NET Framework Development Center

on the Microsoft Web site.

In addition, t
he ASP.NET team has created extensions that incorporate new functionality, such as
support

for AJAX
,

the
Mo
del View Controller (
MVC
)

development pattern
, and
Rich Internet
Applications (
RIA
)

development
.
For information about MVC applications, see
How to: Deploy an
ASP.NET MVC Application

on the MSDN

Web site. For information about RIA applications, see
Deploying a RIA Services Solution

on the MSDN Web site.

The extensions are available as separate
downloads

that can be installed. Th
e
func
tionality
in the
extensions is
incorporated
(or
is
intended to be incorporated)
into subsequent releases of the .NET
Framework. For example, AJAX support was initially released as an
extension

that could be used with
ASP.NET 2.0 or ASP.NET 3.0. The AJAX fu
nctionality was subsequently incorporated into ASP.NET 3.5.
From the hosting perspective, this means that if you have installed ASP.NET 3.5, AJAX functionality is

2


an inherent part of ASP.NET. However, if your server is running versions 2.0 or 3.0 of the .N
ET
Framework, you
must

install the ASP.NET AJAX extension
before you can

offer this functionality for
hosted sites.

AJAX functionality is

not available for ASP.NET 1.1.

This whitepaper addresses features that are available in
ASP.NET 4
. Unless otherwise no
ted, the
information presented in this wh
itepaper applies to ASP.NET 4

and later releases. Features or issues
that apply to a specific release are called out in the text.

For information about the new features in ASP.NET 4, see the
ASP.NET 4 and Visual Studio 2010 Web
Development Overview

on
the
ASP
.net

Web site
.

Trust Levels and ASP.NET Features

Trust levels
let

you define security rules. They define what types of operations an application can
perform, such as reading from disk or

accessing the registry. E
ach trust leve
l has an associated policy
file
,

except for

Full trust. When an application runs with Full trus
t, code access security places no
restrictions on the resources and operations that the application
is allowed to

access.
Access to
r
esource
s

is based on operating system security and Microsoft Windows
®

access control lists (ACLs).
Full trust is mapped to
an internal handler, so it is not possible to edit the
user rights

to perform
operations

for an application.

Full trust is effectively the absence of an application domain policy, and
therefore it never has an associated policy file.

To protect ASP.NET ap
plications, you can restrict
access to
resources and the operations

that

they

can
perform. You do this by setting the
<trust>

element to a predefined trust level in either the machine
-
level Web.config file or the application’s Web.config file.

The followin
g list describes the predefined trust levels:



Full



Applications that run at Full trust level can execute arbitrary native code in the process
context in which they run
.

Because of the inherent risks that come with running in Full trust
mode, this mode is

not recommended in a shared environment except when every Web site
uses its
own application pool and

application pool identity.

Important

The default trust level is Full trust. You should evaluate the security
requirements for your environment and set
the trust level appropriately.



High



Code in High

trust applications can use most .NET Framework permissions that support
partial trust. This mode is often appropriate for
trusted
applications that you want to run with
fewer
user rights

in order
to mitiga
te risks. For example,
this level provides
the same
access
as
Full trust,
but restricts access to unmanaged code and COM interop
.



Medium



Code in Medium trust applications can read and write in its own application
directories and can interact with
Microso
ft
SQL Server™ databases.
However,
by default,
the
user rights that are needed

to access OLE

DB and ODBC are not granted to Medium trust
applications.

Medium trust is the recommended setting for a shared server, because it allows
connections to SQL Server
databases and restricts
most

other
user rights

to the application root
structure.



Low



Code in Low trust applications can read its own application resources
but cannot make
any out
-
of
-
process calls, such as
calls to
a
database,
to the
network,
and so on
.
By using Low
trust, you effectively lock applications down to their application directory and remove all access
to system resources.



Minimal



Code in Minimal trust applications can execute but cannot interact with any
protected resources. Minimal trust ma
y be appropriate for mass hosting sites that want to
support dynamic generation of Hypertext Markup Language (HTML) and isolated business logic.


3


The definition of the trust levels is essentially the same from ASP.NET

version 1.1 through version 4
.
However,

some of the
user rights

or operations that can be granted at each trust level vary slightly.
For example, in
ASP.NET 2.0 and later, Medium
t
rust

code can enable access to OLE

DB

APIs.

For information about how to run ASP.NET applications in a hosted envir
onment, including trust levels
and code access security,
download the
Microsoft Solution for Windows
-
based Hosting version 3.5

tool

kit

from the Microsoft download center.

For
information about
hosting
environments and architecture
,
see

the

Hosting Guidance for the Microsoft Web Platform

on the IIS.net Web site.

Additional

Resources

For more information about trust levels and code access security
user rights that are

provided by each
trust level in ASP.NET, see the following topics on the MSDN Web site:



For information about code access security and the supported
user right
s

types and
configuration attributes, see

Code Access Security in ASP.NET 4 Applications
.



For information about
how to select an appropriate trust level for your application
,

and
how to
create a

custom ASP.NET code access security policy file to define a custom trust level
, see

How
To: Use Code Access Security in ASP.NET 2.0
.



For information about how to use
code access securit
y and Medium trust to provide application
isolation
when
you are
running
multiple applications on the same server,
see
How To: Use
Medium Trust in ASP.NET 2.0
.

Trust Level Recommendations for
Hosters

The following are g
eneral recommendations for
assigning
trust levels
in shared
hosting
environments
:



Hosters should not use Full trust in shared

hosting
scenarios
.
Medium trust is recommended f
or
Web servers that are Internet
-
facing. When applicati
ons run under Full trust,
they are fully
trusted on the server. E
ven if they are isolated by process
,

and even when
user rights

are
limited, applications can access
content from other trusted applications, as well as
access many
system resources, such as t
he registry
and
event logs.



Run e
ach Web site in its own application pool.



Lock down
user rights

for access to the file system for each Web site.

Some applications might need certain features like the ability to use OLE

DB or enhanc
ed .NET
reflection permi
ssions.
By default, t
his type of functionality is not permitted in Medium trust.
If an
application requires code
access security
user rights

that do not exactly
match a predefined trust
level
,
you can
create a custom trust level. For example, rather than u
sing Full trust in order to support
OLE

DB, you can create a new trust level that enables
the particular set of

user rights

that
are needed
for the application.

Customizing Trust Level Policy

Predefined trust
level policies are implemented by using XML
files
.

When a predefined trust level policy
does not meet your security requirements, you can create a customized policy by modifying an
existing predefined policy.

With this approach, you do the following:



Copy one of the existing trust
level policy files

to create a custom policy file.



Add the required
user rights

to the custom policy file.



Configure the machine
-
level Web.config
file
to use the custom policy.


4


The following procedure describes an example of how to create a customized trust level policy tha
t
modifies the default
user rights

for accessing the OLE

DB

API.

To create
a

custom trust level configuration file and add a new permission

1.

Copy the Medium trust policy file,
web_MediumTrust.config
, to create a new policy file in the same
directory
.
By def
ault, the file is located in the following folder:

32
-
bit:
%windir%
\
Microsoft.NET
\
Framework
\
v4.0.30319
\
CONFIG
\

64
-
bit:
%windir%
\
Microsoft.NET
\
Framework
64
\
v4.0.30319
\
CONFIG
\

Give the new file a name that indicates that it

is a variation of
the
Medium trust

configuration
file
,

f
or
example
,
web_MediumTrustOleDb.config
.

2.

Open the new trust configuration file and add the
OleDbPermission

security class definition to the
<SecurityClass>

section, as shown in the following example:

<SecurityClass Name="OleDbPermission"
Description="System.Data.OleDb.OleDbPermission, System.Data,
Version=
4
.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>

3.

Add the unrestricted OleDbPermission to the

"ASP.Net" named permission set, as shown in the
following example:

<PermissionSet


class="NamedPermissionSet"


version="1"


Name="ASP.Net">


...


<IPermission class="OleDbPermission"


version="1"


Unrestricte
d="true"/>


...

</PermissionSet>

The

example
above
provides all user rights to any OLE
D
B

data
source on the server.

You can use more restrictive
user rights

definition
s to allow OLE
DB
to be used by

only specific
data access technologies. The following example restricts access to only Microsoft Access:

<
IPermission class=
"
OleDbPermision
"

version
="1"

>


<add ConnectionString=
"
Provider=Microsoft.Jet.OLEDB.4.0
"


KeyRestrictions="data source=;user

id=;password=;"


KeyRestrictionBehavior="AllowOnly"/>

</IP
ermission>

4.

Open the

default Web.config file
to add the custom trust level that references the custom trust
configuration file
that
you have created.

By default, the file is located in the fol
lowing folder:

32
-
bit:
%windir%
\
Microsoft.NET
\
Framework
\
v4.0.30319
\
CONFIG
\

64
-
bit:
%windir%
\
Microsoft.NET
\
Framework64
\
v4.0.30319
\
CONFIG
\

5.

In the Web.config file, add a new
<trustLevel>

element to the
<securityPolicy>

section to
define a new level named "Custom" and to associate it with the new custom policy file
, as shown
in the following example:

<location allowOverride="
false
">


<system.web>


<securityPolicy>


<trustLevel name="Full" policyFile="internal" /
>


<trustLevel name="High" policyFile="web_hightrust.config" />


<trustLevel name="Medium" policyFile="web_mediumtrust.config" />


<trustLevel name="Low" policyFile="web_lowtrust.config" />


5



<trustLevel name="Minimal" policyFile="web_mi
nimaltrust.config"
/>


<trustLevel name="Custom"
policyFile="web_mediumtrustoledb.config"/>


</securityPolicy>



<trust level="
Custom
" originUrl="" />


</system.web>

</location>

When you save the
machine
-
level
Web.config file, the new settings are in
effect

for all Web
applications on the current server.

Locking the Trust Level

If
you

want to use code access security to ensure application isolation and to restrict access to
system
-
level resources,
you

must defin
e security policy at the machine level and prevent individua
l
applications from overriding this setting
.
You should also lock the trust level for all Web applications
that are running on the same server
.

To lock the trust level

1.

O
pen the machine
-
level Web.c
onfig file
. By default, the file is located in the following folder:

32
-
bit:
%windir%
\
Microsoft.NET
\
Framework
\
v4.0.30319
\
CONFIG
\

64
-
bit:
%windir%
\
Microsoft.NET
\
Framework64
\
v4.0.30319
\
CONFIG
\

2.

E
nclose the
<trust>

element in a
<location>

element, and set the
allowOverride

attribute to
false
, as shown in the following example
:

<location
allowOverride="false"
>


<system.web>


<securityPolicy>


<trustLevel name="Full" policyFile="internal" />


<trustLevel name="High" policyFile="web_hightrust.config" />


<trustLevel name="Medium" policyFile="web_mediumtrust.config" />


<trustLevel name="Low" policyFile="web_lowtrust.config" />


<trustLevel name="Minimal" policyFile="web_minimaltrust.config" />


</securityPolicy>


<trust level="
Medium
" or
iginUrl="" />


</system.web>

</location>

You

can also lock other sections so that they cannot be overwritten by Web.config files tha
t appear
lower in the hierarchy by

using the
<location>

element and the
allowOverride

attribute.

Setting Multiple Trust Leve
ls for Applications

It is recommended that
you

lock the trust level to prevent individual applications from assigning Full
trust and gaining
user rights

that
you
might not have
intended
. If a trust level is specified and no
override is allowed, all applica
tions on the server will run in that trust level and

will

not
be able to set
their own trust, nor perform any operations that are not
allowed

by that trust level.

However, some applications on the server might need different
user rights

than
are provided
by
the
trust level that
you have

specified. For example, a control panel or billing application might require
different
user rights
.

Do not

assign a different trust level to an application simply because a customer’s application will not
run in
your

chosen trust level. By enabling that application to run in a higher trust level, you might
place other applications or your server at risk. An example
of this would be

a hosting site that runs in
Medium trust, but that also provides one application the ab
ility to run in Full trust. The application is

6


no longer restricted to Medium trust operations and has
user rights

to access resourc
es outside of its
own directory

or to read from the registry.


To set the trust level for a specific application


1.

Open the m
achine
-
level Web.config file. By default, the file is located in the following folder:

32
-
bit:
%windir%
\
Microsoft.NET
\
Framework
\
v4.0.30319
\
CONFIG
\

64
-
bit:
%windir%
\
Microsoft.NET
\
Framework64
\
v4.0.30319
\
CONFIG
\

2.

C
reate a second
<trust>

element
in the

Web.conf
ig file.
As shown in the following example,
e
nclose the new
<trust>

element in a
<location>

element, set the
allowOverride

attribute to
false
,

and add a
path

attribute
. The
path

attribute should contain th
e URL of the Web site, such
as Contoso.com or C
ontoso.com/thisvirtualdirectory, to specify which application is assigned this
custom trust level.

<location allowOverride="false" path="contoso.com">


<system.web>


<trust level="Medium" originUrl="" />


</system.web>

</location>

Providers in ASP.NET

Ma
ny features of ASP.NET 2.0 and later
versions
rely on providers to store and retrieve data from a
data source. For example, ASP.NET membership relies on a membership provider to store and retrieve
user authentication data, and the ASP.NET profile manager u
ses a profile provider to store and
retrieve user settings and personal data. Other features that use providers include site navigation, role
management, Web Parts, and personalization.

For each feature, a provider is included that uses
a
SQL Server Expre
ss or SQL Server database. All
built
-
in providers can store and retrieve data by using the same database.

Note

Some features include a provider for other data sources, such as the Windows token role
provider or the Authorization Manager Role provider. I
n addition, a custom provider can be
implemented that works with different data sources and with custom data schemas.

T
he machine
-
level Web.config file
has

configuration elements that specify SQL Server providers for
each of the ASP.NET features that
use

a

provider. By default, these providers are configured to
connect to the local instance of SQL Server Express Edition.
For example, in the
<connectionStrings>

element of the M
achine.config file, the
connectionString

attribute points to
an instance of SQL Se
rver Express
and to the App_Data folder of ASP.NET Web sites
.

SQL Server Express is not ins
talled on the server by default

and
should not be used in shared
hosting
scenarios
.

You should c
hange the configuration information so that it does not point to an
i
nstance of
SQL Server Express.
A typical strategy is to provide each hosted site with its own SQL Server
database and connection string that the site owner can use to create any required ASP.NET ap
plication
services data tables.

For more information about

how to configure
SQL Server for hosted environments, see
SQL Server
2008 for Hosters

on the
IIS
.net

Web site.


7


Configuring a Database for Use with ASP.NET Providers

Y
ou can use the
Aspnet_regsql.exe tool

to configure a database for use with providers
.
For information
about
how to use this tool, see
ASP.NET IIS Registration Tool (Aspnet_regiis.exe)

on
the
MSDN

Web
site
.


Fr
equently Asked Questions

Who provisions the schema
:
the hoster or the customer?

Typically, the
hoster provides a connection string that the customer can use to access a
database. When a Web site is deployed, the customer should
use the connection string to
create (or re
-
create) the
schema.

Can a hoster allow customers to provision the schema?

T
o provision the schema, the database user needs

the following user rights:

db_datareader,
db_datawriter, db_ddladmin, and db_securityadmin
.
The

hoster
must
determine whether to
provide this level of access to customers.

Why are db_ddladmin and db_securityadmin needed to provision the schema?

The database objects (views, stored procedures, roles, and tables)
are

automatically created
with th
e owner set to dbo. Hosters are
restricted from
grant
ing

dbo access to the database
user account

due to
certain
user rights

that it allows.
T
o provision
an object with
dbo

as the
owner to a user account that is not a dbo, the

db_ddladmin and db_securityadm
in
rights
are
needed
,

in addition to
the
normal
user rights

of
db_datareader and db_datawriter
.

Running
Multiple Versions of
ASP.NET Together

ASP.NET

provides a high degree of

backward

compatibility
.
You can run

an ASP.NET
2.0, 3.0, or 3.5

application on a server that has
both

ASP.NET

2.0 and
4

or later installed. Alternatively, you can run
ASP.NET
2.0

and ASP.NET
4

and l
ater applications side
-
by
-
side.

Backward Compatibility

In the context of the .NET Framework, backward compatibility means
that an application created
by
usin
g a

version of the .NET Framework will run on a
ny

later version.

Most applications created
by
using version
2
.0
, 3.0, or 3.5 will run on version 4
. However, applications
might need to be modified so that they will run as
expected. For example, existing applications should
be evaluated to determine whether they are running at optimum performance levels. If performance is
not optimum, the application can be modified or migrated to the latest version of ASP.NET.

For informati
on about changes between ASP.NET 4 and earlier versions that can potentially affect
applications that you have created
by
using earlier versions, see
ASP.NET 4 Breaking Changes

on the
ASP.net We
b site.


Running ASP.NET Side
-
by
-
Side

Side
-
by
-
side execution is the ability to install multiple versions of the .NET Framework
on the same
computer
so that an application can choose which version to use. Subsequent installations of ot
her
versions of the
runtime, an application, or

a component will not affect applications that are already
installed.

For information about side
-
by
-
side support in ASP.NET, including scenarios and supported tasks, see
the
ASP.NET Side
-
by
-
Side Execution Overview

on the MSDN Web site.


8


For information about how to associate individual ASP.NET applications with a specific version of the
CLR when you have

multiple versions of the .NET F
ramework installed,

see
How to: Host Web
Applications That Use Different Versions of the .NET Framework on the Same Server

on the MSDN
Web site.


ASP.NET IIS Registration Tool

The ASP.NET IIS Registration tool (Aspnet_regiis.exe)
is used to register ASP.NET applications with
Internet Information Services (IIS). With this tool, you can register or remove the .NET Framework
ASP.NET installation

by

using IIS
, create new ASP.NET application pools, and display the status of all
installe
d versions of ASP.NET.

The .NET Framework 4

includes a version of the tool that has new features and capabilities. These
features are available
only
when yo
u install the .NET Framework 4

on Windows Vista, Windows Server
2008, or Windows 7.

For more
information about the ASP.NET IIS Registration tool, see

ASP.NET IIS Registration Tool
(Aspnet_regiis.exe)

on MSDN
and

How to set an

IIS Application or AppPool to use ASP.NET 3.5 rather
than 2.0

on Scott Hanselman’s blog
.

Additional Resources

To download a different version of the .NET Framework, follow the appropriate link from the following
list
:



.NET Framework version 1.1
.



.NET Framework version 2.0
.



.NET Framework version 3.5
.



.NET Framework version 4.0
.

SMTP Configuration

The
<mailSettings>

element in the configuration file configures e
-
mail
delivery

options. This element
can be
included

in

an applicati
on
-
level Web.config file or in

the machine
-
level Web.config file
,

if
you
want to provide default
SMTP settings
for the server.

By providing a default in the root
-
level

Web.config

file
, you are allowing all applications on the server
to take advantage of the e
-
mail settings. If you provide e
-
mail support only to certain cus
tomers, do
not set the
<mailSettings>

element in the machine
-
level Web.config file.

E
-
mail delivery methods include:



Using a Simple Mail Transfer Protocol (SMTP) server that you provide.



Moving e
-
mail messages into the pickup directory for the SMTP serve
r built into IIS, which then
delivers the message.



Moving e
-
mail messages to a directory specified by the
p
ickupDirectoryLocation

attribute of
the
<specifiedPickupDirectory>

element for delivery by another application.

Certain controls have dependencies on

the e
-
mail settings. For example, the
PasswordRecovery

contr
ol relies on the e
-
mail settings

and requires access to a working SMTP server. Other controls use
e
-
mail settings optionally, such as the
CreateUserWizard

and
ChangePassword

controls. Third
-
party

controls might also need to send e
-
mail messages.


9


SMTP Configuration Example

The following example specifies SMTP parameters to send e
-
mail by using a remote SMTP server. The
example shows how to configure explicit user credentials.

Note

Sections in the Web.config file that contain sensitive information
such as user names or
passwords
should be encrypted. For more information, see
Encrypting Configuration Infor
mation
Using Protected Configuration

on the MSDN Web site.

<system.net>


<mailSettings>


<smtp deliveryMethod="Network
"
>


<network



defaultCredentials="false"


from="name@contoso.com"


host="smtphost"


port="25"


password="
password"


userName="
user
"/>


</smtp>


</mailSettings>

</system.net>

ASP.NET Configuration API

There are many ways to create and edit ASP.NET configuration files
,

which include the machine
-
level
Web.config file

and
individual a
pplication Web.config files. You can use
a
text editor, the ASP.NET
management console
, or the ASP.NET configuration API.

The
IIS management console
provides a convenient way to manage ASP.NET configuration settings at
all levels on a Web server.
In
Window
s Vista,
Windows Server 2008,
Windows Server 2008 R2, and
Windows 7,
you use IIS Manager.
As of ASP.NET version 2.0, the management console includes
settings for ASP.NET.

The console
uses the ASP.NET configuration API, but it simplifies the process of
edit
ing configuration settings by providing a graphical user interface (GUI).

The ASP.NET configuration API provides the following capabilities:



Provides an integrated view of data from all levels of the configuration hierarchy.



Supports deployment tasks, incl
uding creating configurations and configuring multiple
computers with one script.



Provides a single programming interface for developers who build ASP.NET applications, console
applications and scripts, Web
-
based management tools, and MMC snap
-
ins.



Prevent
s developers and administrators from making invalid configuration settings.



Enables developers to extend the configuration schema. Developers can define new
configuration parameters and write configuration section handlers to process them.



S
upports batch e
xecution across multiple servers.

The ASP.NET configuration system provides a managed interface for programmatically configuring
ASP.NET applications without directly editing the XML configuration files. The ASP.NET

configuration
system simplifies many tasks, including the following:



Writing a script that configures the same ASP.NET application on any or all of the servers in
a
Web farm.


10




Locking some of the settings that are used for each instance of the application.



Creating an automated audit process that records the configuration settings of deployed
applications to ensure that the installation on each
server

is configured the same way.



Editing a change in configuration once, and then applying the change to all the

instances of the
application, wherever they are installed.

Additional Resources

For more

information about how
to
create and edit ASP.NET configuration files
, see

the
following
articles on the MSDN Web site:



For more information about how to write tools
by
using the
c
onfiguration API, see
Using the
Configuration Classes

and
How to: Access ASP.NET Configuration Setting
s Programmatically
.



For more information about how to
configure ASP.NET
W
eb applications and control how the
applications behave
, see
s
ystem.
w
eb Element (ASP.NET Settings Schema)
.




For infor
mation about
features in the configuration system

that are new as of ASP.NET 2.0, see
What’s New in ASP.NET Configuration
.

WebPermission in Medium Trust

The goal of
c
ode
a
ccess
s
e
curity (CAS) is to reduce the attack surface
of
applications
that are
running
on the
.NET Framework
by enabling applications to run with
the
minimum
user rights

that are required
to function. For more general information about

how to
us
e

CAS with ASP.NET
, see
Chapter 19


S
ecuring Your ASP.NET Application and Web Services

on the Microsoft Patterns and Practices Web site.

It is

recommend
ed

that
you

r
un in Medium trust
. M
ost applications will function correctly
,

and
Medium
trust provides
a good level of protection
for the
server and
for
other applications on
the
server.
However, functionality
that is sometimes
used by
W
eb developers
can
require additio
nal
user rights

that are not
enabled
by default
in
M
edium trust.
I
ncreasingly
,
W
eb applications
must

make cross
-
application
W
eb service calls. For example, an e
-
commerce
W
eb site
might need to
make a
W
eb
service call
to get
credit

card authorization.

By default,
WebPermission

is
allowed to make requests to any domain.


Note that
an application with
the default

WebPermission

access could also make requests that are
dangerous
, such as the following
:



An application could make a call to administrative
W
eb
services on the internal network. If your
administrative
W
eb services are not locked down,
espec
ially if they run in Full trust
, you
must
make sure
that other applications on the network cannot reach them.



An application could launch a denial
-
of
-
service (
DOS) attack against other
W
eb servers on your
network or
on
the
I
nternet.



I
f the application is making

requests through a proxy server



w
hich is re
commended



t
he
requests
might
not be tracked
, d
epending on how you track bandwidth
.



An application could bypass restrictions
defined in the
customErrors

configuration section
and
might be able to obtain detailed error information

for
other
application
s

on the server
, including
a stack trace and the physical path.

Some of the ways in which

you can mitigate these risks include the following
:



Set a default proxy server in the Web server’s root
-
level Web.config

file
, and do not allow
applications to override this setting. This prevents applications from making direct Web service
calls to other

computers on the network
; this, in turn, prevents these applications from
being

11


able to
bypass the proxy server.
Using a root
-
level proxy server in this way
also prevents
requests to other applications on the server from appearing as if they originate fro
m localhost
,

preventing

the
requests
from
obtain
ing

detailed error information.



Make sure
that firewall
settings
prevent outbound HTTP

and
HTTPS traffic from the
W
eb server.
This means that an application cannot make a direct call to a server or site on th
e
I
nternet
; all
outbound
calls must go through the proxy server
.



Add or configure
the
proxy server to allow requests from the
W
eb servers to
I
nternet resources.
Make
sure that you log requests from the
W
eb servers

so
that
if any abuse
is detected,
you can
determine which
application is causing it
.



A
llow the
W
eb server to make proxy requests
only
to the
I
nternet, not to the internal network.



Throttle the number of requests that go through the proxy server.
I
f you do not throttle the
number of reques
ts, a DOS attack
could be
launched from your
W
eb server by a hosted
application.

Enabl
ing

defaultProxy

Follow the procedure in this section to configure
a

default proxy server.

To configure a default pro
xy server

1.

Open the machine
-
level Web.config file
.
By
default, the file is located

in the following folder:

32
-
bit:
%windir%
\
Microsoft.NET
\
Framework
\
v4.0.30319
\
CONFIG
\

64
-
bit:
%windir%
\
Microsoft.NET
\
Framework64
\
v4.0.30319
\
CONFIG
\

2.

In the
defaultProxy

element

in
<system.net>
, s
et the
usesystemdefault

attribute
to
false
,
and
then add the
<p
roxyaddress
>

and
<b
ypassonlocal
>

child elements
,

as shown in the
following example

(substitute the correct URL for
your

proxy server address):

<system.net>


<defaultProxy>



<proxy usesystemdefault="false"


proxyaddr
ess=
http://proxyserver


bypassonlocal=
"
false
"

/>


</defaultProxy>

</system.net>

3.

Add a
<location>

element and set its
allowOverride

attribute to
false
. This prevents an
application from changing
defaultProxy

settings at the application level
.

The
<
location>

element looks like the following example

(substitute the correct URL for the proxy server
address)
:

<location allowOverride=
"
true
"
>


<system.net>



<defaultProxy>


<proxy usesystemdefault=
"
false
"



proxyaddress=
http://proxyserver


bypassonlocal=
"
false
"

/>


</defaultProxy>


</system.net>

</location>

For information about the
defaultProxy

element, see
defaultProxy Element (Network Settings)

on
the MSDN Web site.


12


Enabl
ing

WebPermission in a Custom Trust Level

This
proc
edure
assumes that you have already created a custom trust level based on Medium trust, as
described
i
n

Customizing Trust Level Polic
y
.


To enable WebPermission in a custom trust level

1.

Open
the
custom trust file that you created.
By default, the
file
is
located
in the following folder:

32
-
bit:
%windir%
\
Microsoft.NET
\
Framework
\
v4.0.30319
\
CONFIG
\

64
-
bit:
%windir%
\
Microsoft.NET
\
Framework64
\
v4.0.30319
\
CONFIG
\

2.

Edit the
WebPermission

settings
to remove
the
ConnectAccess

element and
to set
the
Unrestricted

attribute
to
true
, as shown in the following example
:

<IPermission class="WebPermission"


version="1"


Unrestricted="tru
e"

/>


...

Setting
the
U
nrestricted

attribute
to
true

enables all
W
eb requests to any destination.
However,
by also configuring
the
defaultProxy

element
and

by

adding other restrictions to your network
infrastructure, you are adding layers of defense to help prevent misuse of the
WebPermission

settings
.

For information about
the
WebPermissi
on

class
, see
WebPermission Class

on the MSDN Web site
.

WebPermission in High Trust

As a best practice, production servers should not be used for development. Therefore, the
user rights
that are granted by
Full trust are not needed on producti
on servers.
The following two entries

in the
Web.config file

are needed only
during the
develop
ment of

partial trust Web applications in Visual
Studio 2010:



Microsoft.VisualStudio.Enterprise.AspNetHelper



Microsoft.VisualStudio.Web

Delete these entries in
the Web.config file in the following section:

<location allowOverride="true">


<system.web>



<fullTrustAssemblies>

By default, the Web.config file is located in the following folder:


32
-
bit:
%windir%
\
Microsoft.NET
\
Framework
\
v4.0.30319
\
Config
\


64
-
bit:
%windir%
\
Microsoft.NET
\
Framework64
\
v4.0.30319
\
Config
\

Code Access Security in ASP.NET 4

Code access security (CAS) is the .NET Framework security mechanism (the “sandbox”) that is used
by ASP.NET to enforce constraints on the ability to execute cod
e. In ASP.NET 4 there are several
changes to CAS from ASP.NET 2.0 and 3.5.
For information about the ASP.NET 2.0 and 3.5 CAS
configuration, see
ASP.NET 2.0/3.5 Shared Hosting Configuration

on th
e IIS.net Web site.

For more
information about CAS in ASP.NET 4, see
Code Access Security in ASP.NET 4 Applications

on the
MSDN Web site.


13


Changes to the ASP.NET 4 Medium Trust Configuration File

The Medium trust level is defined in two configuration files:
W
eb_
M
edium
T
rust.config for the

new

default CAS mode, and L
egacy.
W
eb_
M
edium
T
rust.config for the legacy CAS mode.
The following
change

w
as

made in ASP.
NET 4 to both
configuration files:



The “Refl
ectionPermission” </IPermission /> element with the “RestrictedMemberAccess” flag
has been added by default. In ASP.NET 3.5, this element was added by the .NET Framework
installation process as an update to the pre
-
existing ASP.NET 2.0 configuration files
to support
LINQ. In ASP.NET 4, this installation step no longer occurs because all partial trust
configuration files have
incorporated this change
.

The following changes were made only to the Medium trust configuration file for the default CAS mode
in ASP.
NET 4. The following changes exist only in the
W
eb_
M
edium
T
rust.config file:



The “WebPermission” <IPermission /> element has been set to unrestricted. In previous
ASP.NET releases, as well as in the legacy CAS mode for ASP.NET 4, the WebPermission was
locked down by default. However, with the prevalence of Internet
-
based services, many Web
applications require HTTP access to other sites on the Internet. Rather than requiring explicit
configuration by shared hosting administrators, ASP.NET 4 defaults to
an unrestricted
WebPermission.



The “Microsoft_Strong_Name” and “ECMA_Strong_Name” <CodeGroup /> definitions at the
bottom of the configuration file have been removed. These code groups were from the initial
CAS implementation in ASP.NET 1.1 and are no long
er needed.



The “TypeDescriptorPermission” <IPermission /> element has been added to the configuration
file. This permission enables partial trust code to register custom type descriptors for other
partial trust code. This enables certain functionality for
features such as ASP.NET’s Dynamic
Data and WCF RIA Services.

Reverting ASP.NET 4 to the Legacy CAS Mode

This procedure describes how to revert ASP.NET 4 to the legacy CAS mode.

To revert ASP.NET 4 to the legacy CAS mode

1.

Open the machine
-
level Web.config
file. By default, this file is located in the following folder:

32
-
bit:
%windir%
\
Microsoft.NET
\
Framework
\
v4.0.30319
\
CONFIG
\

64
-
bit:
%windir%
\
Microsoft.NET
\
Framework64
\
v4.0.30319
\
CONFIG
\

2.

Edit the
<trust>

element to set the
legacyCasModel

attribute to
true
,
as shown in the following
example:

<
trust level
="
Medium
"
legacyCasModel
="
true
"
/
>

3.

Save your changes, and then reset the server.

Configuring Content to Serve from a Remote File Server

For machines
that use

the
new
default CAS mode
, it is no longer necessary to modify machine CAS
policy. By default, ASP.NET 4 no longer intersects its CAS policy with machine
-
level policy. ASP.NET
assigns partial trust
user rights

based on the settings defined in the “level” attribute of the <trust />

element. Whether or not an application
’s

file structure is local or remote, the permission set defined
by the “level” attribute of the <trust /> element will be applied to the application.


14


Common Location for Microsoft
AJAX
Library

The Microsoft
AJAX
Libr
ary 3.5 can be used by ASP.NET application
s

and
by
applications

that use
other
W
eb technolog
ies, such as
HTML pages, PHP,
and
Ruby on
Rails.
T
o support
the use of this library,
you

should
make the library's
J
ava
S
cript
files available
in a common location o
n
the
hosted network.
For information about
how to download

the
Microsoft
AJAX
Library 3.5
, see the
downloads page

on the
ASP.NET AJAX Web site.

ASP.NET also offers a Microsoft Ajax Content Delivery Networ
k (CDN) service that provides caching
support for AJAX libraries. You can use this service to add the jQuery and ASP.NET AJAX script
libraries to your Web sites and have your sites automatically served from one of thousands of edge
-
cache servers around the

world.
For

more

information about the Microsoft AJAX CDN and how to u
se
this service with ASP.NET 4
, see
Scott Guthrie’s blog

and
Stephen Walther’s blog

about the Microsoft
Ajax CDN and the jQuery Validation Library.

Hosting Scenarios and Recommendations

Most hosting scenarios involve a shared Web server that hosts hundreds or thousands of Web sites.
These Web sites need rich functio
nality while also being isolated from each other, because these sites
do not run as
trusted code.
T
his section

discuss
es

recommendations for
shared hosting

environments.

Trust Levels for a Shared Hosting Environment

As discussed in
Trust Levels and ASP.NET

Features
,
you should never run in Full trust

because Full
trust
place
s

no
restrictions on the operations
that
an application can perform. Instead, a partial trust
level should be used. The recommended trust
level is Medium, which allows many common operations
and restricts many of the potentially dangerous operations. If
you need to permit
more operations
than Medium trust allows, you should create a custom trust level.

You

can create customized trust levels
based on
your

needs. With a custom trust policy,
you

c
an

base
the permission set on Medium trust; for example, this can permit users to read from Microsoft Access
databases. For more information about how to customize default trust level policies, see
Customizing
Trust Level Policy
.

It is also important that
you

always lock down the trust level so that it cannot be changed by an
application lower in the hierarchy. If unlocked, an application
can
change its own
trust level to Full
trust and perform operations on the server
,

such as reading from the registry or accessing file
s
outside its own path.

Hosting and Isolating Multiple Applications

When hosting multiple Web sites on a single server,
you

should consider how to isolate the
applications from each other. Medium trust provides some sandboxing and isolation. Each application
runs in its own application domain.

B
y default
,

Medium trust allows an application to write only within its own applicat
ion directory. Even
if NTFS file system
user rights

are set so that an application has permissions to a directory outside its
root path, code access security prevents it from accessing that directory.

For
user rights

such as O
LE
D
B

permission for Microsof
t Access files, you can use ACLs. When you use
Microsoft Access with O
LE
D
B
, Microsoft Access code is used to manipulate the file system. Only file
ACLs can provide proper isolation at that point.


15


Isolating by Application Pool

Running each application in
its own application pool and configuring it with a unique process identity
offers an additional level of isolation. Each application then has its own process, and if the application
stops responding, it does not affect other sites on the server. By having
a process with its own
identity, physical content can be secured to only allow access for that identity. This is a robust and
secure method of isolation, but one that can consume many resources by having a larger number of
processes.

Using application pool

isolation might be a good approach if the following apply to your hosting
environment:



You d
o not have a large number of sites active at a given time
.




You a
ggressively recycle based on memory limits
.




Y
ou shut down idle processes
.

For information
about
how to
isolat
e

multiple applications on a server, see
Chapter 20


Hosting
Multiple Web Applications

on the M
SDN Web site
.

In Windows
Server 2008 SP2 and IIS 7
, the concept of using proc
ess isolation through separate user
accounts generated for each application pool is enforced
by using AppPoolIdentity as the default

application pool identity
.

For information about the default application pool identity, see
Application Pools: Configuration
Reference
,
Application Pool Identities
, and
Web Developer Tip #98
:
Did You Know…

on
the IIS
.net

Web site
.

Note:

Using application pool isolation can limit the number of sites that you can host. To increase the
number of sites that you can host, you can use multiple application domains in each application pool.
There is a
limit to the number of application domains that you can have in a single application pool. To
maximize the number of sites that you can host, you can use multiple application pools, each with
approximately 100 application domains.

Hosting a WCF Service in
ASP.NET

In .NET
Framework 4
, Windows Communication Foundation (WCF) is enabled by default during
installation. This behavior differs from

.NET
Framework
3.5, which required that you explicitly enable
WCF after installation. However, note that if you instal
l IIS

7

after you install

.NET
Framework
4, the
*.svc extension will not be registered. To resolve this issue, run the following

command
:

aspnet_regiis.exe /iru

To host WCF services in ASP.NET, you must
set the aspNetCompatibilityEnabled setting to
true
.

T
he
.NET Framework 4 also adds WCF support for Multiple Site Bindings. To use this feature

with
WCF
services
,
you must
set

the multipleSiteBindingsEnabled setting
to
true
, as shown in the following
example:

<system.serviceModel>


<serviceHostingEnvironment
aspNetCompatibilityEnabled="true"


multipleSiteBindingsEnabled="true" ... />

</system.serviceModel>

For more information about
how to
host WCF services, see
Hosting

on the MSDN Web site.


16


Using
ASP.NET in a Web Farm

In a Web farm,
you

must run multiple front
-
end Web servers with a back
-
end server for content
storage. Instead of using a physical drive path for the Web site, a
Universal Naming Convention

(UNC)
share is defined for the Web site.

Whe
n content is on a UNC share, and if you are using unmanaged code, you should protect access to
your files by using a unique identity
for

each application pool.

For information about unique
identities
,
see
Application Pool Identities

on the IIS.net Web site.

To serve content from a UNC share

1.

Configure the home directory for the Web site to be a UNC share.
In

the
Connect As

option
,
specify
a

unique user identity to use.


2.

Grant
Read

user rights

for the
unique

user and the process identity (the user account configured
for the application pool in which the site runs) on the physical directory.

3.

Run the following command to g
rant the
unique

user Full control to the

Temporary ASP.NET Files
folder

or
to
the temporary directory for the

application that is specified in the
tempDirectory

attribute of the
compilation

configuration element.

aspnet_regiis.exe
-
ga
Custom_Account_Name

4.

Grant the
unique

user
List files and Delete

user rights

to the
%windir%
\
Temp
\

directory
.

5.

If the process identity is a domain or custom user,
run the following command to
add the
appropriate
user rights
. If your process identity is Network Service, this step is not necessary.

a
spnet_regiis.exe
-
ga
ActiveDirectoryDomain
\
ProcessIden
tity

Note

The Aspnet_regiis.exe tool is located in the
following directory:

32
-
bit:
%windir%
\
Microsoft.NET
\
Framework
\
v4.0.30319
\


64
-
bit:
%windir%
\
Microsoft.NET
\
Framework64
\
v4.0.30319
\

For more information
about how to use
a custom process identity with ASP.NET, see
How To: Create a
Service Account for an ASP.NET 2.0 Application

on the MSDN Web site
.

Making Sure
That Application State Will Be Maintained in

a Web
Farm

If an application is deployed in a Web farm, the configuration files on each server need to share the
same value for the
validationKey

and
decryptionKey

attributes of the
machineKey

configuration
setting, which are used for
hashing and decrypti
on, respectively. This is required because you cannot
guarantee which server will handle successive requests. If this is not done, visitors to the site might
see the error
:

"The state information is invalid for this page and might be corrupted." By default
,
these settings are automatically generated
,

which

means that they will be different on each server in
the Web farm. For more information about how to work with application
s

deployed in a Web farm, see
the following articles:



Fix:
"
The View State Is Invalid for This Page and Might Be Corrupted
"

Error Message in ASP.NET

on the Microsoft Help and Support Web site.



How To: Configure Mac
hineKey in ASP.NET 2.0

on the MSDN Web site.


17


Features That Affect Hosters

The following sections describe features that have changed since .NET Framework version 1.1 and that
affect hosters.

Access Databases: Using
OLE

DB
and ODBC Providers in Medium
Trust


In ASP.NET 2.0 and later, applications can read or write Access databases in partial trust; they do not
require Full trust. As noted earlier, the
OLE

DB
managed data provider does not demand Full trust,
although by default
OleDbPermission

is not granted
to Medium trust applications. This means that you
can access an
OLE

DB
data source, such as an .mdb Access database file, in partial trust.

T
o enable
the
necessary
user rights

for applications to read and write .mdb files in partial trust, you
must create a custom trust policy file as described in
Trust Levels and ASP.NET 2.0 Features
.

Application Domain Resource Monitoring

Applic
ation domain resource monitoring (ARM) lets you monitor CPU and memory usage by application
domain. You can use the information provided by ARM to determine whether a particular application
domain is adversely affecting other application domains or the per
formance of an entire process.

This
feature is particularly useful for hosts such as ASP.NET that use many application domains in a long
-
running process.

For information about how to enable resource monitoring, see
Application Domain Resource Monitoring

on the MSDN Web site.

Performance Benefits in ASP.NET 2.0 and Later

In ASP.NET 1.1, the framework modules (system.web.dll, system.data.dll, system.xml.dll, and so on)
must be just
-
in
-
time compiled

("jitted") in each application domain. In ASP.NET 2.0 and later, the
framework modules have native images that are generated by the Ngen.exe tool. These images are
loaded domain
-
neutral and are shared across multiple application domains. Additionally, the

native
images are loaded just like any other DLL

the memory can be shared by multiple processes.

Performance changes made in ASP.NET 2.0 can provide the following benefits:



An increase

in the number of applications



m
easured by application domains



t
hat

can be
hosted.



An increase in the number of worker processes per
computer
, often as much as 80 percent
more.

The benefits may vary on hosted servers, where content is uploaded by many different users and
might be inefficient or resource
-
intensive.

Session

State Compression

By default, ASP.NET provides two options for storing session state across a Web farm. The first option
is a session state provider that invokes an out
-
of
-
process session state server, and the second option
is a session state provider tha
t stores data in a Microsoft SQL Server database.
Because both options
store state information outside a Web application’s worker process, session state must be serialized
before it is sent to remote storage. If a large amount of data is saved in session s
tate, the size of the
serialized data can become very large.


18


ASP.NET 4

introduces a compression option for both kinds of out
-
of
-
process session state providers.
By using this option, applications that have spare CPU cycles on Web servers can achieve substa
ntial
reductions in the size of serialized session state data.

For information about
how to set

this option, see
What’s New in ASP.NET 4 and Visual Web Developer

on the MSDN Web site.

WOW64 Comp
atibility: Running 32
-
bit Applications on a 64
-
bit
Server

O
ne of the performance benefits of the x64 platform is that it increases virtual address space, so
that
more memory is available. Standard
x86

systems can map
a maximum of

4 GB of memory. With 2 GB
reserved for the operating system, only 2 GB remains for the application. You can increase the
application virtual address space to 3 GB by setting a
/3GB

switch in the Windows B
oot.ini file.

The 64
-
bit platform offers 8 TB of memory for applications (the user virtual address space), with
another 8 TB reserved for the operating system. This is a substantial increase in memory that can be
used by Windows. However, some Web sites might have 32
-
bi
t applications that cannot be run on 64
-
bit. For such circumstances, IIS can be configured to start a 32
-
bit worker process, enabling
Microsoft
Windows on Windows 64
(WOW64) compatibility for 32
-
bit Web applications on a 64
-
bit server.

It is

recommend
ed

th
at you run hosting customers
in 32
-
bit application pools on

64
-
bit operating system
s

and hardware.

The user virtual addres
s space for a WOW64 application

is 4

GB; however, the .NET
Framework
CLR

is
able to use
only
3

GB of this address space. Nonetheless,
WOW64 applications also benefit from a
non
-
paged

pool size of 128

GB, just
as native x64 applications do. U
sing
the
/3GB

switch
on an x86
machine reduces the size of
a
non
-
paged

pool
.

T
herefore
,

there are clear advantages to moving to
WOW64
.

For informatio
n about
how to
enabl
e

WOW64 compatibility mode, see
Microsoft Windows Server 2003
SP1 enables WOW64 compatibility for 32
-
bit Web applications in IIS 6.0

on the Microsoft Help an
d
Support Web site.

Deploying ASP.NET Step
-
by
-
S
tep

This section provides an overview of the steps that are required to install ASP.NET

on

a new server
and to configure
the
recommended settings.

To
set up and deploy ASP.NET

1.

Download and install the .NET Framework on
your

Web server.

2.

(Optional)
Add a custom trust policy based on Medium trust. To do so, cop
y the Medium trust
policy file,
W
eb_
M
ediumTrust.config
,

to a new p
olicy file. By default, the file is located in the
follow
ing folder:

32
-
bit:
%windir%
\
Microsoft.NET
\
Framework
\
v4.0.30319
\
CONFIG
\

64
-
bit:
%windir%
\
Microsoft.NET
\
Framework64
\
v4.0.30319
\
CONFIG
\

Give the new policy file a name that indicates that it is a variation of

the

Medium trust

configuration file
,

f
or
example
,

W
eb_MediumTrustCustom.config.

Note:

This step is optional. Add a custom trust policy only if you are substantially modifying the
Medium trust configuration.


3.

Add the OleDbPermission security class definition to the
<SecurityClass>

section in the
W
eb_MediumTrustCustom.config

file, as shown in the following example:

<SecurityClass Name="OleDbPermission"



19



Description="System.Data.OleDb.OleDbPe
rmission, System.Data,


Version=4
.0.0.0,


Culture=neutral,


PublicKeyToken=b77a5c561934e089"/>

4.

Add the unrestricted OleDbPermission to the "ASP.Net" named permission set, as shown in the
following example
:

<PermissionSet

class="NamedPermissionSet"

version="1"

Name="ASP.Net">



<IPermission class="OleDbPermission"


version="1"


Unrestricted="true"/>


...

</PermissionSet>

The

previous
example
provides all user rights

to any O
LE
D
B

data
source on the server.

You can use a more restrictive
user rights

definition to allow O
LE
DB to
use
on
ly specific data
access technologies. The following example restricts access to only Microsoft Access:

<IPermission class="OleDbPermision" version="1" >


<add ConnectionString="Provider=Microsoft.Jet.OLEDB.4.0"


KeyRestrictions="data source=;user id
=;password=;"


KeyRestrictionBehavior="AllowOnly"/>

</IPermission>

5.

Modify the default Web.config file to add the custom trust level that references the custom trust
configuration file
that
you have created.

The
Web.config
file is located in the follo
wing
folder
:

32
-
bit:
%windir%
\
Microsoft.NET
\
Framework
\
v4.0.30319
\
CONFIG
\

64
-
bit:
%windir%
\
Microsoft.NET
\
Framework64
\
v4.0.30319
\
CONFIG
\

6.

Add a new
<trustLevel>

element to the
<securityPolicy>

section of the Web.config file to
define a new level called "Custom
.
"
A
ssociate it with the custom policy file
,

and
then
l
ock the trust
level so that it cannot be changed by applications on the server. To do so, set the
allowOverride

attribute of the
<loc
ation>

element to false, as shown in the following example:

<location allowOverride="false">


<system.web>


<securityPolicy>


<trustLevel name="Full" policyFile="internal" />


<trustLevel name="High" policyFile="web_hightrust.config" />


<tr
ustLevel name="Medium" policyFile="web_mediumtrust.config" />


<trustLevel name="Low" policyFile="web_lowtrust.config" />


<trustLevel name="Minimal" policyFile="web_minimaltrust.config" />


</securityPolicy>


<trust level="Medium" originUrl=
"" />


</system.web>

</location>

For more information about this step, see
Locking the Trust Level
.

7.

Configure ASP.NET for a Web site

by doing the following:


a)

In IIS Manager, in the
Connections

pane,
select your
application
.

b)

In the
Actions

pane, click
Basic Settings…
.


c)

In the
Edit Application

dialog box, click
Select…
.

d)

In the
Select Application Pool

dialog box, select
ASP.NET v4.0

from the
A
pplication
pool list
, and then click
OK
.


20


e)

Click
OK

to close the
Edit
Application

dialog box.

For
m
ore
i
nformation

about this step, see
Running ASP.NET Side
-
by
-
Side
.

8.

If the process identity is not
AppPoolIdentity
, c
onfigure a custom process identity for the server
application pool.

To do so, run the Aspnet_regiis.exe tool with the

ga

switch.
If you do not
perform this step,
ASP.NET Web pages
will

run,
but
could

experience permissions errors. T
his step
configures the proper
user rights

for the custom accounts.

The following example

shows the syntax for the Aspnet_regiis
.exe

command that you use for this
step
:

Aspnet_regiis.exe
-
ga
ActiveDirectoryDomain
\
ProcessIdentity

ActiveDirectoryDomain

is the domain that the application pool account is part of, if this is a
domain account.
ProcessIdentity

is the user account that is configured as the identity of the
application pool.

For more information about this step,
see
Using ASP.NET 2.0 in a Web Farm
.

For information about the default applicatio
n pool identity, see
Application Pool Identities

on
the
IIS
.net

Web site
.

9.

Add the provider schemas

to the associated SQL database

by
using SQL Server commands
,

as

shown in the following example:

EXEC sp_addrolemember 'aspnet_Membership_FullAccess', 'SqlDbUser'

EXEC sp_addrolemember 'aspnet_Personalization_FullAccess', 'SqlDbUser'

EXEC sp_addrolemember 'aspnet_Profile_FullAccess', 'SqlDbUser'

EXEC sp_addrolemember 'aspnet_Roles_FullAccess', 'SqlDb
User'

EXEC sp_addrolemember 'aspnet_WebEvent_FullAccess', 'SqlDbUser'

SqlDbUser

is the SQL user name that will be used in the customer’s Web.config file to
configure connection strings.

For more information about this step, see
Configuring a Database for Use with ASP.NET Providers
.

Additional Resources

For
how
-
to guidance
on
a variety of scenarios in ASP.NET
, see

the

Patterns and P
ractices Security How
Tos Index

on the MSDN Web site.