Datasheet

Assuming aspnet_regiis -ga has been used, when the ISAPI extension is initializing the application
domain and is running as either a local or domain account, it will use neither LSA nor HKU and will
instead create and access the auto-generated machine key information underneath:
HKLM\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0\AutoGenKeys\SID
From all of this discussion, it should also be a bit clearer why using an auto-generated machine key in a
web farm doesn’t work. Regardless of which account is used for an ASP.NET application, the auto-gener-
ated machine key is local to a specific machine and furthermore to a specific user identity. As a result,
applications running in a web farm (or in the case of forms authentication, applications running under
different identities that need to recognize a common forms authentication ticket) must use explicit values
for the
validationKey and decryptionKey attributes in the <machineKey /> configuration element.
Explicit key values are the only way in ASP.NET 2.0 to ensure that the same keys are deployed on differ-
ent machines. The DPAPI feature does not support exporting key material from one machine to another,
so you don’t have the option in a web farm of using the
AutoGenerate setting. Realistically, configuring
either of these attributes with
AutoGenerate is only useful for smaller applications that can afford to
run as standalone black boxes.
Initializing the Compilation System
During the last steps of application domain initialization, ASP.NET 2.0 initializes various aspects of its
compilation system.
ASP.NET registers a custom assembly resolver to handle type load failures that arise when the .NET
Framework cannot load a type that was defined in the
App_Code directory. Code in the App_Code directory
is compiled into in an auto-generated assembly that is assigned a random name. Each time a developer
changes a piece of code that lives within the
App_Code directory, ASP.NET will recompile the App_Code
directory, which results in one or more new assemblies with different names (there can be subdirectories in
App_Code that in turn give rise to multiple assemblies). As a result any operations that depended on the
assembly name for a class located in
App_Code (binary serialization for instance will write out the name of
the assembly containing the serialized type) would fail without the ASP.NET custom assembly resolver. The
resolver redirects requests for types from
App_Code related assemblies to the most current versions of these
auto-generated assemblies.
The ASP.NET runtime then ensures that various globally referenced assemblies are compiled and avail-
able. This includes ensuring the auto-compiled output for
App_Code, the global and local resource
directories, the
app_webreferences directory and global.asax are up to date. As part of this process-
ing, ASP.NET also starts file monitoring on
global.asax. If any changes subsequently occur to
global.asax, the changes cause the application domain to recycle.
First Request Initialization
With the application domain up and running, ASP.NET performs some initializations that occur only
during the first request to the application domain. In general, these one-time tasks include the following:
❑ Caching the impersonation information so that ASP.NET knows the impersonation mode that is
in effect for the application, as well as caching security tokens if application impersonation is
being used or if the application is running on a UNC share.
❑ Configuration settings from
<httpRuntime />, <globalization />, and <processModel
/>
are loaded. The interesting point here is that you can use the <httpRuntime /> element to
turn off a website.
23
Initial Phases of a Web Request
04_596985 ch01.qxp 12/14/05 7:46 PM Page 23