Overview of the ASP. NET application life cycle for IIS 5.0 and 6.0

This topic provides an overview of the life cycle of an ASP. NET application, lists important life-cycle events, and describes how the code you write adapts to the application life cycle. The information in this topic applies to IIS 5.0 and IIS 6.0. For information about the ASP. NET application life cycle in IIS 7.0, see Overview of the ASP. NET application life cycle of IIS 7.0.

In ASP., to initialize an ASP. NET application and make it handle the request, you must perform some processing steps. In addition, ASP. NET is only part of the WEB server structure that processes requests made by the browser. It is important to understand the application lifecycle so that you can write code at the appropriate life cycle stage to achieve the desired results.

Application life Cycle Overview

The following table describes the various phases of the ASP. NET application life cycle.

The

Stage	Description
User requests application resources from the WEB server. The	The lifecycle of an ASP. NET application starts with a browser sending a request to a WEB server (for an ASP. NET application, typically IIS). ASP. NET is an ISAPI extension under a WEB server. When a WEB server receives a request, it checks the file name extension of the requested file, determines which ISAPI extension should process the request, and then passes the request to the appropriate ISAPI extension. The file name extensions, such as. aspx,. ascx,. ashx, and. asmx, that are mapped to ASP. Description: Description: If you want to create a custom handler that serves a specific file name extension, you must do so in the IIS Mapping the extension to ASP. NET, you must also register the handler in the application's Web. config file. For more information, see HTTP Handlers and HTTP Module overview.
ASP. NET receives the first request to an application.	When ASP. NET receives the first request for any resource in the application, the class named Applicationmanager creates an application domain. Application domains provide application isolation for global variables and allow each application to be uninstalled separately. In the application domain, an instance is created for the class named Hostingenvironment that provides access to information about the application, such as the name of the folder where the application is stored. The following diagram illustrates this relationship: If required, ASP. NET also compiles the top-level items in the application, including the application code in the App_Code folder. For more information, see "Compilation Life Cycle" later in this topic.
Create an ASP. NET core object for each request.	After you have created the application domain and instantiated the Hostingenvironment object, ASP. NET creates and initializes the core objects, such as HttpContext, HttpRequest, and HttpResponse. 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, including all rendered output and cookies.
Assigning a HttpApplication object to a request	After all of the core 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.asax class (derived from the HttpApplication class) and uses that derived class to represent the application. Description: when you request an ASP page or process in your application for the first time, a new instance of HttpApplication is created. However, to maximize performance, you can reuse HttpApplication instances for multiple requests. When you create an instance of HttpApplication, all the configured modules are created at the same time. For example, if you configure your application this way, ASP. NET creates a SessionStateModule module. After all the configured modules have been created, the Init method of the HttpApplication class is called. The following diagram illustrates this relationship:
The request is processed by the HttpApplication pipeline.	The following events are executed by the HttpApplication class when the request is processed. Developers who want to extend the HttpApplication class need to be aware of these events in particular. 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. Depending on the file name extension of the requested resource (mapped in the application's configuration file), select the class that implements IHttpHandler to process the request. If the request is for an object (page) derived from the page class, and the page needs to be compiled, ASP. NET compiles it before creating an instance of the page. 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 ihttpasynchandler.beginprocessrequest) 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 EndRequest event. Raises the Presendrequestheaders event. Raises the Presendrequestcontent event.

life cycle Events and Global.asax files

During the life cycle of an application, an application raises an event that can be handled and invokes a specific method that can be overridden. To handle application events or methods, you can create a file named Global.asax in the application root directory.

If you create a Global.asax file, ASP. NET compiles it to a class that derives from the HttpApplication class and then uses that derived class to represent the application.

An instance of the HttpApplication process processes only one request at a time. This simplifies the application's event-handling process because it does not need to be locked when accessing non-static members in an application class. This also allows the request-specific data to be stored in non-static members of the application class. For example, you can define a property in the Global.asax file, and then assign a request-specific value to the property.

By using a naming convention application_event (such as application_beginrequest), ASP. NET can automatically bind application events to handlers in the Global.asax file. This is similar to the method of automatically binding an ASP. NET page method to an event, such as a page's Page_Load event. For more information, see the ASP. NET page life cycle Overview.

The Application_Start and Application_End methods are special methods that do not represent HttpApplication events. During the life cycle of an application domain, ASP. NET calls these methods only once, not once for each HttpApplication instance.

The following table lists some of the events and methods that are used during the application life cycle. These events are more than just listed, but these events are most commonly used.

Event or method	Description
Application_Start	Called when the first resource, such as a page, is requested in an ASP. The Application_Start method is called only once during the life cycle of the application . You can use this method to perform startup tasks, such as loading data into the cache and initializing static values. Only static data should be set during application startup. Because instance data can only be used by the first instance of the HttpApplication class that is created, do not set any instance data.
Application_Event	Thrown at the appropriate time in the application life cycle, see what is listed in the Application Life table earlier in this topic. Application_Error can be raised at any stage of the application life cycle. Because the request is shorted, Application_EndRequest is the only event that can guarantee that each request will be raised. For example, if there are two modules that handle the Application_BeginRequest event, and the first module throws an exception, the Application_BeginRequest event is not called for the second module . However, the Application_EndRequest method is always called to make the application clean up resources.
Init	Once all the modules have been created, they are called once for each instance of the HttpApplication class.
Dispose	Called before the application instance is destroyed. You can use this method to manually release any unmanaged resources. For more information, see Scavenging unmanaged resources.
Application_End	Called once for each application life cycle before uninstalling the application.

Compile life cycle

When a request is made for the application for the first time, ASP. NET compiles the application items in a specific order. The first items to compile are called top-level items. After the first request, the top-level item is recompiled only if the dependency changes. The following table describes the order in which you compile the ASP.

Item	Description
App_GlobalResources	Compiles the application's global resources and generates the resource assembly. Any assembly in the application's Bin folder is linked to the resource assembly.
App_webresources	Create and compile a proxy type for the WEB service. The generated WEB reference assembly is linked to the resource assembly, if present.
Configuration file properties defined in the Web. config file	If the configuration file properties are defined in the application's Web. config file, an assembly that contains the profile object is generated.
App_Code	Generate a source code file and create one or more assemblies. All code assemblies and configuration file assemblies are linked to resources and WEB reference assemblies, if any.
Global.asax	Compiles the Application object and links it to all previously generated assemblies.

After compiling the application's top-level entries, ASP. NET will compile the folders, pages, and other items as needed. The following table describes the order in which you compile the ASP.

Item	Description
App_LocalResources	If the folder containing the requested item contains the App_LocalResources folder, the contents of the local resource folder are compiled and linked to the global resource assembly.
Individual web pages (. aspx files), user controls (. ascx files), HTTP handlers (. ashx files), and HTTP modules (. asmx files)	Compile and link to local resource assemblies and top-level assemblies as needed.
Themes, master pages, other source files	Compile the appearance files for each theme, master page, and other source code files that are referenced by those pages when you compile the reference page.

The compiled assembly is cached on the server and reused on subsequent requests, and is retained between application restarts as long as the source code has not changed.

Because the application compiles on the first request, the initial request to the application takes significantly longer than the subsequent request. You can precompile the application to reduce the time that is required for the first request. For more information, see How to: Precompile an ASP.

Application restarts (number of application restarts)

Modifying the source code of the WEB application will cause ASP. NET to recompile the source file into an assembly. When you modify a top-level item in an application, all other assemblies in your application that reference the top-level assembly are also recompiled.

In addition, modifying, adding, or removing certain types of files in the application's well-known folders will cause the application to restart. The following actions will cause the application to restart:

• Add, modify, or delete an assembly in the application's Bin folder.

• Add, modify, or delete localized resources in the App_GlobalResources or App_LocalResources folder.

• Add, modify, or delete an application's Global.asax file.

• Add, modify, or delete source code files in the App_Code directory.

• Add, modify, or delete configuration file configurations.

• Add, modify, or delete Web service references in the App_WebReferences directory.

• Add, modify, or delete the Web. config file for your application.

When an application requires a restart, ASP. NET will service all pending requests from the existing application domain and from the old assembly before restarting the application domain and loading the new assembly.

Overview of the ASP. NET application life cycle for IIS 5.0 and 6.0