Overview of the ASP. NET application life cycle of IIS 7.0 (reproduced)

Overview of the ASP. NET application life cycle for IIS 7.0
Updated: November 2007
This topic describes the application life cycle of an ASP. NET application that runs in Integrated mode in IIS 7 and that runs with IIS 7.0 or later versions. IIS 7.0 also supports Classic mode, which behaves like an ASP. For more information, see the ASP. NET application Life cycle overview for IIS 5.0 and 6.0.
The IIS 7 integrated pipeline is a unified request processing pipeline that supports both native code and managed code modules. The managed code module that implements the IHttpModule interface can access all events in the request pipeline. For example, managed code modules can be used for ASP. NET Forms authentication for ASP. aspx files and HTML pages (. htm or. html files). This is true even if IIS and ASP. HTML pages are considered static resources. For more information about the IIS 7 integration mode, see ASP. NET Integration with IIS7 (integrate ASP. NET with IIS7).
This topic contains the following sections:
Structure overview
Life cycle Phase
Using the Global.asax file
Managed-code modules in IIS 7.0
Structure overview
Requests in the IIS 7 Integrated mode go through several stages, similar to the stages that are experienced by requests for ASP. NET resources in IIS 6.0. However, in IIS 7.0, these stages contain several additional application events, such as Maprequesthandler, Maprequesthandler, and Maprequesthandler events.
The main difference between the processing phases of IIS 7.0 and IIS 6.0 is how ASP. NET integrates with the IIS server. In IIS 6.0, there are two request processing pipelines. A pipeline is used for native code ISAPI filters and extension components. Another pipeline is used for managed code application components, such as ASP. In IIS 7.0, the ASP. NET runtime integrates with the WEB server, so there is a unified request processing pipeline for all requests. For an ASP. NET developer, the integration pipeline has the following benefits:
The integrated pipeline throws all the events exposed by the HttpApplication object, which enables existing ASP. NET HTTP modules to work in the IIS 7 Integrated mode.
Both native code and managed code modules can be configured at the Web server level, at the site level, or at the Web application level. This includes built-in ASP. NET managed code modules for session state, Forms authentication, configuration files, and role management. In addition, managed code modules can be enabled or disabled for all requests, regardless of whether the request is for an ASP. NET resource (such as an ASPX file).
Managed code modules can be called at any stage in the pipeline. This includes before any server processing of the request, after all server processing has occurred, or at any stage between the two.
You can register the module through the application's Web. config file, or you can enable or disable the module.
The following illustration shows the configuration of the application's request pipeline. The example includes the following:
Anonymous native code modules and Anonymous managed code modules (corresponding to FormsAuthenticationModule). These modules are configured and are called during the authentication phase of the request.
Basic native code module and Windows managed code module (corresponding to WindowsAuthenticationModule). Although they are displayed, they are not configured for the application.
In the Execute handler phase, handlers are invoked (modules that are scoped to the URL) to construct the response. For. aspx files, use the PageHandlerFactory handler to respond to requests. For static files, native code staticfilemodule modules respond to requests.
Trace native code module. Although this module is displayed, it is not configured for the application.
Custom module managed code class. This class is called in the LOG request phase.
Request Pipeline in IIS 7.0
For information about known compatibility issues with ASP. NET applications that are migrated from earlier versions of IIS to IIS 7.0, see Upgrading ASP. Applications to IIS 7.0:differences between IIS 7.0 Integrated mode and Classic mode (Upgrade the ASP. NET application to IIS 7.0:iis 7 The difference between integrated and classic modes) "known Differences between Integra Ted mode and Classic mode (known differences between integrated and classic modes) section.
Life cycle Phase
The following table lists the phases of the ASP. NET application life cycle that runs in IIS 7 Integrated mode.
Stage
Description
Issue a request for application resources.
The life cycle of an ASP. NET application starts with the browser sending requests to the WEB server.
In IIS 7.0 Classic mode and in IIS 6.0, the ASP. NET request pipeline is detached from the WEB server pipeline. The module applies only to requests routed to the ASP. NET ISAPI extension. If the file name extension of the requested resource type is not explicitly mapped to ASP. asp, the net feature is not called for the request because the ASP. NET runtime does not process the request.
In the case of IIS 7 integration mode, all requests are processed by a single unified pipeline. When the integration pipeline receives the request, the request goes through some phases that are common to all requests. These stages are represented by the Requestnotification enumeration. All requests can be configured to use the ASP. NET feature because it is encapsulated in a managed code module that can access the request pipeline. For example, a request to an HTML page still calls an ASP. NET module, even if the. htm file name extension is not explicitly mapped to ASP. This enables you to use ASP. NET authentication and authorization for all resources.
The unified pipeline receives the first request to the application.
When the unified pipeline receives the first request for any resource in the application, an instance is created for the Applicationmanager class, which is the application domain that processes the request. application domains provide a separation of global variables between applications and allow each application to be unloaded separately. In the application domain, an instance is created for the Hostingenvironment class that provides access to information about the application, such as the name of the folder where the application is stored.
During the first request, if necessary, the top-level items in the application are compiled, including the application code in the App_Code folder. You can include custom modules and handlers in the App_Code folder, as described in the managed code modules in IIS 7.0 later in this topic.
A response object is created for each request.
After you have created the application domain and instantiated the Hostingenvironment object, the application objects, such as HttpContext, HttpRequest, and HttpResponse, are created and initialized. The HttpContext class contains objects that are specific to the current application request, such as HttpRequest and HttpResponse objects. The HttpRequest object contains information about the current request, including Cookie and browser information. The HttpResponse object contains the response sent to the client, which includes all rendered output and cookies.
The following are some key differences between IIS 6.0 and IIS 7.0 (running in Integrated mode with the. NET Framework 3.0 or later):
You can use the Substatuscode property of the HttpResponse object to set code that is useful for failed request tracing. For more information, see Troubleshooting Failed requests using Failed request tracing in IIS 7.0 (using the failed Request tracing feature in IIS 7.0 to resolve problems with failed requests).
The Headers property of the HttpResponse object provides access to the response headers of the responses.
When an event handler handles multiple HttpApplication events, you can use the two properties ispostnotification and Currentnotification of the HttpContext object.
The Headers and ServerVariables properties of the HttpRequest object support write operations.
Assigning a HttpApplication object to a request
After all application objects are initialized, the application is started by creating an instance of the HttpApplication class. If the application has a Global.asax file, ASP. NET creates an instance of the Global.aspx class derived from the HttpApplication class. The derived class is then used to represent the application.
Bb470252.alert_note (zh-cn,vs.100). gif description:
The first time an ASP. NET page or process is requested in an application, a new instance of the HttpApplication class is created. However, to maximize performance, you can reuse HttpApplication instances for multiple requests.
which ASP. NET modules (such as SessionStateModule) are loaded depends on the managed code module that the application inherits from the parent application. This also depends on which modules are configured in the configuration section of the application's Web. config file. Add or remove modules from the modules element in the system.webserver section of the application's Web. config. For more information, see How to: Configure <system.webServer> sections for IIS 7.0.
The request is processed by the HttpApplication pipeline.
When a request is processed, the HttpApplication class performs the following tasks. These events are useful for Web page developers who want to run code when a critical request pipeline event is raised. These events are also useful if you are developing a custom module and want to call the module for all requests destined for the pipeline. The custom module implements the IHttpModule interface. In IIS 7 Integrated mode, an event handler must be registered in the module's Init method.
Validation of the request checks the information sent by the browser and determines whether it contains potentially malicious tokens. For more information, see ValidateRequest and Scripting Intrusion Overview.
If any URLs have been configured in the Urlmappingssection section of the Web. config file, the URL mapping is performed.
Raises the BeginRequest event.
Raises the AuthenticateRequest event.
Raises the Postauthenticaterequest event.
Raises the AuthorizeRequest event.
Raises the Postauthorizerequest event.
Raises the Resolverequestcache event.
Raises the Postresolverequestcache event.
Raises the Maprequesthandler event. The appropriate handler is selected based on the file name extension of the requested resource. A handler can be a native code module, such as IIS 7.0StaticFileModule, or a managed code module, such as The PageHandlerFactory class (which handles. aspx files).
Raises the Postmaprequesthandler event.
Raises the AcquireRequestState event.
Raises the Postacquirerequeststate event.
Raises the PreRequestHandlerExecute event.
Call the appropriate IHttpHandler class's ProcessRequest method (or asynchronous version ihttpasynchandlerbeginprocessrequest) for the request. For example, if the request is for a page, the current page instance will process the request.
Raises the PostRequestHandlerExecute event.
Raises the ReleaseRequestState event.
Raises the Postreleaserequeststate event.
If the Filter property is defined, the response filter is executed.
Raises the Updaterequestcache event.
Raises the Postupdaterequestcache event.
Raises the Logrequest event.
Raises the Postlogrequest event.
Raises the EndRequest event.
Raises the Presendrequestheaders event.
Raises the Presendrequestcontent event.
Bb470252.alert_note (zh-cn,vs.100). gif description:
The Maprequesthandler, Logrequest, and Postlogrequest events are supported only when the application is running in IIS 7 Integrated mode and is running with the. NET Framework 3.0 or later.
Using the Global.asax file
The use of the Global.asax file in Integrated mode in IIS 7.0 is similar to the use of IIS 6.0 in ASP. For more information, see the "Lifecycle Events and Global.asax Files" section in the ASP. NET application Life cycle overview for IIS 5.0 and 6.0.
One difference is that you can add handlers for Maprequesthandler, Logrequest, and Postlogrequest events. These events can be supported for applications that run in IIS 7 in Integrated mode and run with the. NET Framework 3.0 or later.
You can provide application event handlers in the Global.asax file to add code that executes for all requests for ASP. aspx and. Axd pages. However, the handler code in the Global.asax file is not called to handle requests for non-ASP. NET resources, such as static files. To run managed code that runs for all resources, create a custom module that implements the IHttpModule interface. The custom module will run to handle all requests for resources in the application, even if the resource handler is not an ASP.
Managed-code modules in IIS 7.0
The ASP. NET managed code modules that you can configure and load in IIS 7.0 include the following:
FormsAuthenticationModule
ProfileModule
RoleManagerModule
SessionStateModule
To configure the IIS 7.0 managed code module, you can use one of the following methods:
Use IIS Manager. For more information, see How to: Open IIS Manager.
Use the IIS 7.0 command-line tool (Appcmd.exe). For more information, see IIS 7.0 command-line tool (IIS 7.0 command-line tools).
Edit the IIS 7.0 XML-based configuration store. For more information, see IIS 7.0:iis 7.0 Configuration store (IIS 7.0:iis 7.0).
When an ASP. NET managed code module (such as the FormsAuthenticationModule module) is configured to load in IIS 7.0, it can access all the events in the request pipeline. This means that all requests will pass through the managed code module. For the FormsAuthenticationModule class, this means that you can use Forms authentication to protect static content, even if the content is not handled by an ASP.
Developing custom managed code modules

You can extend the ASP. NET application life cycle using a module that implements the IHttpModule interface. The module that implements the IHttpModule interface is a managed code module. The integration pipeline for ASP. NET and IIS 7.0 can also be extended through native code modules that are not covered in this topic. For more information about native code modules and about how modules are typically configured, see IIS Module Overview (Overview of IIS Modules).
You can define a managed code module as a class file in the App_Code folder of your application. You can also create a module as a class library project, compile the project, and then add it to the application's Bin folder. After you create a custom module, you must register it in IIS 7.0. You can use one of the methods described to manage IIS 7.0 managed code modules. For example, you can edit the application's Web. config file to register this managed code module with the application. For an example of registering this module, see Walkthrough: Creating and Registering a custom HTTP module.
If a module is defined in the App_Code or Bin folder of the application and is registered in the application's Web. config file, this module is called only for that application. To register a module in the application's Web. config file, you can use the modules element in the system.webserver section. For more information, see How to: Configure <system.webServer> sections for IIS 7.0. Changes are made using IIS Manager or the Appcmd.exe tool, and the Web. config file for the application is also changed accordingly.
Managed code modules can also be registered in the modules element of the IIS 7.0 configuration store (applicationhost.config file). Modules registered in the ApplicationHost.config file have global scope because they are registered for all WEB applications that are hosted by IIS 7.0. Similarly, the native code module defined in the Globalmodules element of the ApplicationHost.config file also has a global scope. If the WEB application does not require a global module, you can disable it.
Example

The following example shows a custom module that handles Logrequest and postlogrequest events. The event handler is registered in the Init method of the module.
Imports System
Imports System.Data
Imports system.web
Imports System.Web.Security
Imports System.Web.UI
Imports Microsoft.VisualBasic
' Module that demonstrates one event handler for several events.
Namespace Samples
Public Class Moduleexample
Implements IHttpModule
Public Sub New ()
' Constructor
End Sub
Public Sub Init (ByVal app as HttpApplication) Implements Ihttpmodule.init
AddHandler app. Logrequest, AddressOf Me.app_handler
AddHandler app. Postlogrequest, AddressOf Me.app_handler
End Sub
Public Sub Dispose () Implements ihttpmodule.dispose
End Sub
' One for both the Logrequest and Postlogrequest events.
Public Sub App_handler (ByVal source as Object, ByVal e as EventArgs)
Dim app as HttpApplication = CType (source, HttpApplication)
Dim context as HttpContext = App. Context
If (context. currentnotification = requestnotification.logrequest) Then
If not (context. Ispostnotification) Then
' Put code here, ' invoked when the Logrequest event is raised.
Else
' Postlogrequest
' Put code here, runs after the Logrequest event completes.
End If
End If
End Sub
End Class
End Namespace
Using System;
Using System.Data;
Using System.Web;
Using System.Web.Security;
Using System.Web.UI;

Module that demonstrates one event handler for several events.
Namespace Samples
{
public class Moduleexample:ihttpmodule
{
Public Moduleexample ()
{
Constructor
}
public void Init (HttpApplication app)
{
App. Logrequest + = new EventHandler (App_handler);
App. Postlogrequest + = new EventHandler (App_handler);
}
public void Dispose ()
{
}
One handler for both the Logrequest and the Postlogrequest events.
public void App_handler (object source, EventArgs e)
{
HttpApplication app = (HttpApplication) source;
HttpContext context = App. Context;

if (context. Currentnotification = = requestnotification.logrequest)
{
if (!context. Ispostnotification)
{
Put code Here's invoked when the Logrequest event is raised.
}
Else
{
Postlogrequest
Put code here, runs after the Logrequest event completes.
}
}

}
}
}

The following example shows how to register a module in the application's Web. config file. Add the system.webserver configuration section inside the config section.
<system.webServer>
<modules>
<add name= "Moduleexample" type= "Samples.moduleexample"/>
</modules>
</system.webServer>
For additional examples of how to create and register custom modules, see Walkthrough: Creating and Registering a custom HTTP module.
Please see
Concept

An overview of the ASP page life cycle
ASP Overview
ASP. NET Compilation overview
Other resources

ASP. NET and IIS configuration
Important statement: The content of the message is the author's own editor, Youdao Yun Note is not responsible for the authenticity and validity of the content. Please contact the author.
Youdao Yun Notes

Overview of the ASP. NET application life cycle of IIS 7.0 (reproduced)