ASP.Net Application Life Cycle
It is important for developers to understand the ASP.NET web application life cycle so that the developers can write code at the appropriate life cycle stage for the intended effect.
The life cycle of an ASP.NET application starts with a request sent by a browser to the Web server (typically IIS).
ASP.NET Application Life Cycle Overview for IIS 7.0
IIS 7 takes ASP.NET further by integrating the ASP.NET runtime extensibility model with the core server.
Existing ASP.NET applications also immediately benefit from tighter integration by using existing ASP.NET features like Forms authentication, roles, and output caching for all content.
In IIS 6.0 and previous releases, ASP.NET was implemented as an IIS ISAPI extension.
In these earlier releases, IIS processed a request to an ASP.NET content type and then forwarded that request to the ASP.NET ISAPI DLL, which hosted the ASP.NET request pipeline and page framework. Requests to non-ASP.NET content, such as ASP pages or static files, were processed by IIS or other ISAPI extensions and were not visible to ASP.NET.
The major limitation of this model was that services provided by ASP.NET modules and custom ASP.NET application code were not available to non-ASP.NET requests.
In IIS 7, the ASP.NET request-processing pipeline overlays the IIS pipeline directly, essentially providing a wrapper over it instead of plugging into it.
IIS 7 processes requests that arrive for any content type, with both native IIS modules and ASP.NET modules providing request processing in all stages. This enables services that are provided by ASP.NET modules, such as Forms authentication or output cache, to be used for requests to
ASP pages,
PHP pages,
static files, and so on.
The following table lists the stages of the ASP.NET application life cycle with Integrated mode in IIS 7.0.
| Stage | Description |
| A request is made for an application resource. |
- The life cycle of an ASP.NET application starts with a request sent by a browser to the Web server.
- In Classic mode in IIS 7.0 and in IIS 6.0, the ASP.NET request pipeline is separate from the Web server pipeline. Modules apply only to requests that are routed to the ASP.NET ISAPI extension. If the file-name extension of the requested resource type is not explicitly mapped to ASP.NET, ASP.NET functionality is not invoked for the request because the request is not processed by the ASP.NET runtime.
- In integrated mode in IIS 7.0, a unified pipeline handles all requests. When the integrated pipeline receives a request, the request passes through stages that are common to all requests. These stages are represented by the RequestNotification enumeration. All requests can be configured to take advantage of ASP.NET functionality, because that functionality is encapsulated in managed-code modules that have access to the request pipeline. For example, even though the .htm file-name extension is not explicitly mapped to ASP.NET, a request for an HTML page still invokes ASP.NET modules. This enables you to take advantage of ASP.NET authentication and authorization for all resources.
|
| The unified pipeline receives the first request for the application. |
- When the unified pipeline receives the first request for any resource in an application, an instance of the ApplicationManager class is created, which is the application domain that the request is processed in.
- Application domains provide isolation between applications for global variables and enable each application to be unloaded separately. In the application domain, an instance of the HostingEnvironment class is created, which provides access to information about the application, such as the name of the folder where the application is stored.
- During the first request, top-level items in the application are compiled if required, which includes application code in the App_Code folder. You can include custom modules and handlers in the App_Code folder.
|
| Response objects are created for each request. | After the application domain has been created and the HostingEnvironment object has been instantiated, 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 the HttpRequest and HttpResponse objects.
- The HttpRequest object contains information about the current request, which includes cookies and browser information.
- The HttpResponse object contains the response that is sent to the client, which includes all the rendered output and cookies.
The following are some key differences between IIS 6.0 and IIS 7.0 running in Integrated mode and with the .NET Framework 3.0 or later:
|
| An HttpApplication object is assigned to the request |
- After all application objects have been initialized, the application is started by creating an instance of the HttpApplication class.
- If the application has a Global.asax file, ASP.NET instead creates an instance of the Global.asax class that is derived from the HttpApplication class. It then uses the derived class to represent the application.
|
| The request is processed by the HttpApplication pipeline. | The following tasks are performed by the HttpApplication class while the request is being processed. The events are useful for page developers who want to run code when key request pipeline events are raised. They are also useful if you are developing a custom module and you want the module to be invoked for all requests to the pipeline. Custom modules implement the IHttpModule interface. In Integrated mode in IIS 7.0, you must register event handlers in a module's Init method.
- Validate the request, which examines the information sent by the browser and determines whether it contains potentially malicious markup. For more information, see ValidateRequest and Script Exploits Overview.
- Perform URL mapping, if any URLs have been configured in the UrlMappingsSection section of the Web.config file.
- Raise the BeginRequest event.
- Raise the AuthenticateRequest event.
- Raise the PostAuthenticateRequest event.
- Raise the AuthorizeRequest event.
- Raise the PostAuthorizeRequest event.
- Raise the ResolveRequestCache event.
- Raise the PostResolveRequestCache event.
- Raise the MapRequestHandler event. An appropriate handler is selected based on the file-name extension of the requested resource. The handler can be a native-code module such as the IIS 7.0 StaticFileModule or a managed-code module such as the PageHandlerFactory class (which handles .aspx files).
- Raise the PostMapRequestHandler event.
- Raise the AcquireRequestState event.
- Raise the PostAcquireRequestState event.
- Raise the PreRequestHandlerExecute event.
- Call the ProcessRequest method (or the asynchronous version IHttpAsyncHandler.BeginProcessRequest) of the appropriate IHttpHandler class for the request. For example, if the request is for a page, the current page instance handles the request.
- Raise the PostRequestHandlerExecute event.
- Raise the ReleaseRequestState event.
- Raise the PostReleaseRequestState event.
- Perform response filtering if the Filter property is defined.
- Raise the UpdateRequestCache event.
- Raise the PostUpdateRequestCache event.
- Raise the LogRequest event.
- Raise the PostLogRequest event.
- Raise the EndRequest event.
- Raise the PreSendRequestHeaders event.
- Raise the PreSendRequestContent event.
 Note
|
Using the Global.asax File
During the application life cycle, the application raises events that you can handle and calls particular methods that you can override. To handle application events or methods, you can create a file named Global.asax in the root directory of your application.
If you create a Global.asax file, ASP.NET compiles it into a class derived from the
HttpApplication class, and then uses the derived class to represent the application.
ASP.NET automatically binds application events to handlers in the Global.asax file using the naming convention
Application_event, such as
Application_BeginRequest. This is similar to the way that ASP.NET page methods are automatically bound to events, such as the page's
Page_Load event.
You can provide application event handlers in the Global.asax file to add code that executes for all requests that are handled by ASP.NET, such as requests for .aspx and .axd pages. However, handler code in the Global.asax file is not called for 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 for all requests to resources in the application, even if the resource handler is not an ASP.NET handler.
ASP.Net life cycle specifies, how:
- ASP.Net processes pages to produce dynamic output
- The application and its pages are instantiated and processed
- ASP.Net compiles the pages dynamically
The ASP.Net life cycle could be divided into groups:
- Application Life Cycle
- Page Life Cycle
The application life cycle has the following stages:
- User makes a request for accessing application resource, a page. Browser sends this request to the web server.
- A unified pipeline receives the first request and the following events take place:
- An object of the ApplicationManager class is created.
- An object of the HostingEnvironment class is created to provide information regarding the resources.
- Top level items in the application are compiled.
- Response objects are created . the application objects: HttpContext, HttpRequest and HttpResponse are created and initialized.
- An instance of the HttpApplication object is created and assigned to the request. The request is processed by the HttpApplication class. Different events are raised by this class for processing the request.
Materiały:
ASP.NET Integration with IIS 7
ASP.NET Application Life Cycle Overview for IIS 7.0
ASP.NET Application Life Cycle Overview for IIS 5.0 and 6.0
The layout on this site has a good feel to it. I’m not sure if it’s the colors or exactly what it is but I’m really enjoying this site.
OdpowiedzUsuń