asp.net application life cycle-msdn__.net

asp.net asp.net application life cycle overview

This topic provides an overview of the application lifecycle, lists important lifecycle events, and describes how to write code that fits the lifecycle of the application. In ASP.net, to initialize a 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 handles requests made by the browser. It is important to understand the application lifecycle so that code can be written at the appropriate lifecycle stage to achieve the desired results. Application life Cycle Overview

The following table describes the phases of the ASP.net application lifecycle.

The

Stage	Description
User requests an application resource from a WEB server. The lifecycle of the	ASP.net application starts with the browser sending requests to the WEB server (for asp.net applications, usually IIS). asp.net is the ISAPI extension under the 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. asp.net handles file extensions that are mapped to them, such as. aspx,. ascx,. ashx, and. asmx. notice If the file name extension has not been mapped to an ASP. NET, ASP.net will not receive the request. It is important to understand this for applications that use ASP.net authentication. For example, because an. htm file is typically not mapped to asp.net, asp.net will not request an authentication or authorization check for an. htm file. Therefore, even if the file contains only static content, if you want ASP.net to check for authentication, you should create the file using a file name extension that maps to asp.net, such as the file extension. aspx. note If you want to create a custom handler that serves a specific file name extension, you must map the extension to ASP.net in IIS, and you must also register the handler in the application's Web.config file. For more information, see an introduction to HTTP handlers.
asp.net receives the first request to the 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 unloaded separately. In the application domain, an instance of the class named Hostingenvironment is created 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 needed, asp.net can also compile top-level items in the application, including application code in the App_Code folder. For more information, see "Compiling a Lifecycle" later in this topic.
Create a asp.net core object for each request.	After the application domain is created and the hostingenvironment object is instantiated, 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 cookies and browser information. The HttpResponse object contains the responses 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. Attention The first time a asp.net page or process is requested in an application, a new instance of HttpApplication is created. However, to maximize performance, HttpApplication instances can be reused for multiple requests. When you create an instance of HttpApplication , all of the configured modules are also created. For example, if you configure the 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 invoked. The following diagram illustrates this relationship:
The request is processed by the HttpApplication pipeline.	The following event is performed by the HttpApplication class when the request is processed. Developers who want to extend the HttpApplication class need to pay particular attention to these events. Validation of the request checks the information sent by the browser and determines whether it contains potentially malicious markup. 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 and process the request. If the request is for an object (page) that derives from the page class, and the page needs to be compiled, ASP.net compiles it before the instance of the page is created. Raises the Postmaprequesthandler event. Raises the AcquireRequestState event. Raises the Postacquirerequeststate event. Raises the PreRequestHandlerExecute event. Invoke the ProcessRequest method (or asynchronous version BeginProcessRequest) of the appropriate IHttpHandler class 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, a response filter is performed. Raises the Updaterequestcache event. Raises the Postupdaterequestcache event. Raises the EndRequest event.

life cycle Events and Global.asax files

During the life cycle of an application, the application raises the events 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's 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 the application class. This also allows you to store the requested data in a Non-static member 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 the naming convention application_event (such as application_beginrequest), asp.net can automatically bind application events to handlers in Global.asax files. This is similar to the method of automatically binding a ASP.net page method to an event, such as a page's Page_Load event. For more information, see 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 only calls these methods once, not every HttpApplication instance.

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

Event or method	Description
Application_Start	Called when the first resource in the application, such as a page, is requested asp.net. Only one Application_Start method is called once during the life cycle of the application. You can use this method to perform a startup task, such as loading data into the cache and initializing a static value. Only static data should be set during application startup. Because instance data can only be used by the first instance of the HttpApplication class you create, do not set any instance data.
Application_ Event	Raised at an appropriate time in the application lifecycle, see the content listed in the Application Life table earlier in this topic. Application_Error can be raised at any stage of the application lifecycle. 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 invoked for the second module. However, the application_endrequest method is always invoked to make the application clean up the resource.
HttpApplication.Init	Once all the modules have been created, each instance of the HttpApplication class is called once.
Dispose	Called before the application instance is destroyed. You can use this method to manually release any unmanaged resources. For more information, see Cleaning Up Unmanaged resources.
Application_End	Called once for each application lifecycle before uninstalling the application.

Compile life cycle

The first time a request is made to an application, ASP.net compiles the application items in a specific order. The first batch of items to compile is called the top-level item. After the first request, the top-level entry is recompiled only if the dependency changes. The following table describes the order in which the top-level items are compiled asp.net.

Item	Description
App_GlobalResources	Compiles the global resources of the application and generates the resource assembly. Any assemblies in the application's Bin folder are 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 it exists.
Profile properties defined in the Web.config file	If the profile property is defined in the application's Web.config file, a assembly containing the configuration file 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 you compile the top-level entries for your application, asp.net compiles folders, pages, and other items as needed. The following table describes the order in which the ASP.net folders and items are compiled.

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	Compiles the skin files for each topic, master page, and other source code files that are referenced by those pages when the reference page is compiled.

The compiled assembly is cached on the server and reused for subsequent requests, and is preserved between application restarts as long as the source code is 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 your application to reduce the time required for the first request. For more information, see How to: Precompile a asp.net web site. Application restarts (number of application restarts)

Modifying the source code of a WEB application causes 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 deleting certain types of files in the known folders of an application 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 profile configurations.

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

Add, modify, or delete an application's Web.config file.

When the application needs to be restarted, 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. HTTP Module

The asp.net application lifecycle can be extended through the IHttpModule class. asp.net contains several classes that implement IHttpModule , such as the SessionStateModule class. You can also create classes that implement IHttpModule yourself.

If you add a module to an application, the module itself raises an event. By using the Modulename_eventname Convention, applications can subscribe to these events in Global.asax files. For example, to handle the authenticate event that is raised by a FormsAuthenticationModule object, you can create a handler named formsauthentication_authenticate .

By default, the SessionStateModule class is enabled in ASP.net. All sessions events are automatically named session _event, such as Session_Start . The Start event is raised each time a new session is created. For more information, see Session State Overview. See Concepts asp.net page life cycle overview
asp.net overview
asp.net compilation Overview
other resources asp.net and IIS configuration