Datasheet

administrator is guaranteed that a malicious configuration section handler cannot make calls into Win32

APIs that attempt to reformat the hard drive (granted this is an extreme example, but you get the idea).

In Chapter 4 “Configuration System Security” the effects of ASP.NET trust levels on configuration will

be discussed in more detail.

Establishing Assembly Locations

With the application domain policy set, ASP.NET performs some housekeeping that allows the .NET

Framework assembly resolution to be aware of the bin directory. This allows the .NET Framework

assembly resolution logic to probe the bin directory and resolve types from assemblies located within

the “bin” directory. Remember that earlier ASP.NET performed some work to set up the code-generation

directory structure. A side effect of this setup is that ASP.NET and the .NET Framework also have the

ability to resolve types located in the application-specific code-generation directory.

ASP.NET also attempts to enable shadow copying of assemblies from the bin directory. Assuming that

shadow copying is enabled, the .NET Framework will make private copies of these assemblies as neces-

sary within the code-generation directory structure for the application. When the .NET Framework

needs to reference types and code from assemblies in the bin directory, the framework will instead load

information from the shadow copied versions. Shadow copying the bin assemblies allows you to copy

new versions of assemblies into the bin directory without requiring the web application to be stopped.

Because multiple web applications may be simultaneously running within a single worker process, the

shadow copying behavior is important; it preserves the ability to maintain uptime for other web applica-

tions. If each application domain maintained a file lock on the assemblies located in the bin directory,

XCOPY deployment of an ASP.NET application would be difficult. An administrator would have to

cycle the entire worker process to release the file locks. With shadow copying, you can copy just new

binaries to the server and ASP.NET will automatically handle shutting down the affected application

domain and restarting it to pick up changes to the bin directory.

ASP.NET 2.0 introduces a new configuration element —

<hostingEnvironment /> — that administra-

tors can used to disable shadow copying. The following configuration when placed within

<system.web /> will disabled shadow copying:

You may want to disable shadow copying if an administrator explicitly disallows overwriting assem-

blies on a production server. Disabling shadow copying would prevent someone from randomly updat-

ing an application’s binaries when the application is already up and running. Also some assemblies

expect that other files exist on the file system in the same directory structure as the assembly. In these

cases, shadow copying causes the assembly to be shadow copied to a completely different directory

structure, thus breaking the assembly’s assumptions about relative file locations.

Obtaining the Auto-Generated Machine Key

If you have ever used viewstate or issued a forms authentication ticket, it is likely that you depended on

an auto-generated machine key to provide security. The default

<machineKey /> configuration for an

ASP.NET application sets both the

validationKey and decryptionKey attributes to

AutoGenerate,IsolateApps. During application domain initialization, ASP.NET ensures that the

auto-generated machine key is available so that ASP.NET applications that depend on automatically

generated keys will have the necessary key material.

Initial Phases of a Web Request

04_596985 ch01.qxp 12/14/05 7:46 PM Page 19