ASP.NET Application and Page Life Cycle

 Introduction
In this article, we will try to understand what the different events are which take place right from the time the user sends a request, until the time the request is rendered on the browser. So we will first try to understand the two broader steps of an ASP.NET request and then we will move into different events emitted from ‘HttpHandler’, ‘HttpModule’ and ASP.NET page object. As we move in this event journey, we will try to understand what kind of logic should go in each and every one of these events.
This is a small Ebook for all my .NET friends which covers topics like WCF, WPF, WWF, Ajax, Core .NET, SQL, etc. You can download the same from here or else you can catch me on my daily free training here.

The Two Step Process

From 30,000 feet level, ASP.NET request processing is a 2 step process as shown below. User sends a request to the IIS:

• ASP.NET creates an environment which can process the request. In other words, it creates the application object, request, response and context objects to process the request.
• Once the environment is created, the request is processed through a series of events which is processed by using modules, handlers and page objects. To keep it short, let's name this step as MHPM (Module, handler, page and Module event), we will come to details later.

In the coming sections, we will understand both these main steps in more detail.

Creation of ASP.NET Environment

Step 1: The user sends a request to IIS. IIS first checks which ISAPI extension can serve this request. Depending on file extension the request is processed. For instance, if the page is an ‘.ASPX page’, then it will be passed to ‘aspnet_isapi.dll’ for processing.

Step 2: If this is the first request to the website, then a class called as ‘ApplicationManager’ creates an application domain where the website can run. As we all know, the application domain creates isolation between two web applications hosted on the same IIS. So in case there is an issue in one app domain, it does not affect the other app domain.

Step 3: The newly created application domain creates hosting environment, i.e. the ‘HttpRuntime’ object. Once the hosting environment is created, the necessary core ASP.NET objects like ‘HttpContext’ , ‘HttpRequest’ and ‘HttpResponse’ objects are created.

Step 4: Once all the core ASP.NET objects are created, ‘HttpApplication’ object is created to serve the request. In case you have a ‘global.asax’ file in your system, then the object of the ‘global.asax’ file will be created. Please note global.asax file inherits from ‘HttpApplication’ class.
Note: The first time an ASP.NET page is attached to an application, a new instance of ‘HttpApplication’ is created. Said and done to maximize performance, HttpApplication instances might be reused for multiple requests.

Step 5: The HttpApplication object is then assigned to the core ASP.NET objects to process the page.

Step 6: HttpApplication then starts processing the request by HTTP module events, handlers and page events. It fires the MHPM event for request processing.
Note: For more details, read this.

The below image explains how the internal object model looks like for an ASP.NET request. At the top level is the ASP.NET runtime which creates an ‘Appdomain’ which in turn has ‘HttpRuntime’ with ‘request’, ‘response’ and ‘context’ objects.

Process Request using MHPM Events Fired

Once ‘HttpApplication’ is created, it starts processing requests. It goes through 3 different sections ‘HttpModule’ , ‘Page’ and ‘HttpHandler’. As it moves through these sections, it invokes different events which the developer can extend and add customize logic to the same.
Before we move ahead, let's understand what are ‘HttpModule’ and ‘HttpHandlers’. They help us to inject custom logic before and after the ASP.NET page is processed. The main differences between both of them are:

• If you want to inject logic based in file extensions like ‘.ASPX’, ‘.HTML’, then you use ‘HttpHandler’. In other words, ‘HttpHandler’ is an extension based processor.
  
• If you want to inject logic in the events of ASP.NET pipleline, then you use ‘HttpModule’. ASP.NET. In other words, ‘HttpModule’ is an event based processor.
  

You can read more about the differences from here.
Below is the logical flow of how the request is processed. There are 4 important steps MHPM as explained below:

Step 1(M: HttpModule): Client request processing starts. Before the ASP.NET engine goes and creates the ASP.NET HttpModule emits events which can be used to inject customized logic. There are 6 important events which you can utilize before your page object is created BeginRequest, AuthenticateRequest, AuthorizeRequest, ResolveRequestCache, AcquireRequestState and PreRequestHandlerExecute.

Step 2 (H: ‘HttpHandler’): Once the above 6 events are fired, ASP.NET engine will invoke ProcessRequest event if you have implemented HttpHandler in your project.

Step 3 (P: ASP.NET page): Once the HttpHandler logic executes, the ASP.NET page object is created. While the ASP.NET page object is created, many events are fired which can help us to write our custom logic inside those page events. There are 6 important events which provides us placeholder to write logic inside ASP.NET pages Init, Load, validate, event, render and unload. You can remember the word SILVER to remember the events S – Start (does not signify anything as such just forms the word) , I – (Init) , L (Load) , V (Validate), E (Event) and R (Render).

Step4 (M: HttpModule): Once the page object is executed and unloaded from memory, HttpModule provides post page execution events which can be used to inject custom post-processing logic. There are 4 important post-processing events PostRequestHandlerExecute, ReleaserequestState, UpdateRequestCache and EndRequest.
The below figure shows the same in a pictorial format.

In What Event Should We Do What?

The million dollar question is in which events should we do what? Below is the table which shows in which event what kind of logic or code can go.

Section	Event	Description
HttpModule	BeginRequest	This event signals a new request; it is guaranteed to be raised on each request.
HttpModule	AuthenticateRequest	This event signals that ASP.NET runtime is ready to authenticate the user. Any authentication code can be injected here.
HttpModule	AuthorizeRequest	This event signals that ASP.NET runtime is ready to authorize the user. Any authorization code can be injected here.
HttpModule	ResolveRequestCache	In ASP.NET, we normally use outputcache directive to do caching. In this event, ASP.NET runtime determines if the page can be served from the cache rather than loading the patch from scratch. Any caching specific activity can be injected here.
HttpModule	AcquireRequestState	This event signals that ASP.NET runtime is ready to acquire session variables. Any processing you would like to do on session variables.
HttpModule	PreRequestHandlerExecute	This event is raised just prior to handling control to the HttpHandler. Before you want the control to be handed over to the handler any pre-processing you would like to do.
HttpHandler	ProcessRequest	Httphandler logic is executed. In this section, we will write logic which needs to be executed as per page extensions.
Page	Init	This event happens in the ASP.NET page and can be used for: Creating controls dynamically, in case you have controls to be created on runtime. Any setting initialization. Master pages and the settings. In this section, we do not have access to viewstate, postedvalues and neither the controls are initialized.
Page	Load	In this section, the ASP.NET controls are fully loaded and you write UI manipulation logic or any other logic over here.
Page	Validate	If you have valuators on your page, you would like to check the same here.
	Render	It’s now time to send the output to the browser. If you would like to make some changes to the final HTML which is going out to the browser, you can enter your HTML logic here.
Page	Unload	Page object is unloaded from the memory.
HttpModule	PostRequestHandlerExecute	Any logic you would like to inject after the handlers are executed.
HttpModule	ReleaserequestState	If you would like to save update some state variables like session variables.
HttpModule	UpdateRequestCache	Before you end, if you want to update your cache.
HttpModule	EndRequest	This is the last stage before your output is sent to the client browser.

A Sample Code for Demonstration

With this article, we have attached a sample code which shows how the events actually fire. In this code, we have created a ‘HttpModule’ and ‘Httphandler’ in this project and we have displayed a simple response write in all events, below is how the output looks like.
Below is the class for ‘HttpModule’ which tracks all events and adds it to a global collection.

Collapse | Copy Code

public class clsHttpModule : IHttpModule
{
...... 
void OnUpdateRequestCache(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnUpdateRequestCache");
}
void OnReleaseRequestState(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnReleaseRequestState");
}
void OnPostRequestHandlerExecute(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnPostRequestHandlerExecute");
}
void OnPreRequestHandlerExecute(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnPreRequestHandlerExecute");
}
void OnAcquireRequestState(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnAcquireRequestState");
}
void OnResolveRequestCache(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnResolveRequestCache");
}
void OnAuthorization(object sender, EventArgs a)
{
objArrayList.Add("httpModule:OnAuthorization");
}
void OnAuthentication(object sender, EventArgs a)
{

objArrayList.Add("httpModule:AuthenticateRequest");
}
void OnBeginrequest(object sender, EventArgs a)
{

objArrayList.Add("httpModule:BeginRequest");
}
void OnEndRequest(object sender, EventArgs a)
{
objArrayList.Add("httpModule:EndRequest");
objArrayList.Add("<hr>");
foreach (string str in objArrayList)
{
httpApp.Context.Response.Write(str + "<br>") ;
}
} 
}

Below is the code snippet for ‘HttpHandler’ which tracks ‘ProcessRequest’ event.

Collapse | Copy Code

public class clsHttpHandler : IHttpHandler
{
public void ProcessRequest(HttpContext context)
{
clsHttpModule.objArrayList.Add("HttpHandler:ProcessRequest");
context.Response.Redirect("Default.aspx");
}
}

We are also tracking all the events from the ASP.NET page.

Collapse | Copy Code

public partial class _Default : System.Web.UI.Page 
{
protected void Page_init(object sender, EventArgs e)
{

clsHttpModule.objArrayList.Add("Page:Init");
}
protected void Page_Load(object sender, EventArgs e)
{
clsHttpModule.objArrayList.Add("Page:Load");
}
public override void Validate() 
{
clsHttpModule.objArrayList.Add("Page:Validate");
}
protected void Button1_Click(object sender, EventArgs e)
{
clsHttpModule.objArrayList.Add("Page:Event");
}
protected override void Render(HtmlTextWriter output) 
{
clsHttpModule.objArrayList.Add("Page:Render");
base.Render(output);
}
protected void Page_Unload(object sender, EventArgs e)
{
clsHttpModule.objArrayList.Add("Page:UnLoad");
}}

Below is how the display looks like with all events as per the sequence discussed in the previous section.

Zooming ASP.NET Page Events

In the above section, we have seen the overall flow of events for an ASP.NET page request. One of the most important sections is the ASP.NET page, we have not discussed the same in detail. So let’s take some luxury to describe the ASP.NET page events in more detail in this section.
Any ASP.NET page has 2 parts, one is the page which is displayed on the browser which has HTML tags, hidden values in form of viewstate and data on the HTML inputs. When the page is posted, these HTML tags are created in to ASP.NET controls with viewstate and form data tied up together on the server. Once you get these full server controls on the behind code, you can execute and write your own login on the same and render the page back to the browser.

Now between these HTML controls coming live on the server as ASP.NET controls, the ASP.NET page emits out lot of events which can be consumed to inject logic. Depending on what task / logic you want to perform, we need to put this logic appropriately in those events.
Note: Most of the developers directly use the page_load method for everything, which is not a good thought. So it’s either populating the controls, setting view state, applying themes, etc., everything happens on the page load. So if we can put logic in proper events as per the nature of the logic, that would really make your code clean.

Seq	Events	Controls Initialized	View state Available	Form data Available	What Logic can be written here?
1	Init	No	No	No	Note: You can access form data etc. by using ASP.NET request objects but not by Server controls.Creating controls dynamically, in case you have controls to be created on runtime. Any setting initialization.Master pages and them settings. In this section, we do not have access to viewstate , posted values and neither the controls are initialized.
2	Load view state	Not guaranteed	Yes	Not guaranteed	You can access view state and any synch logic where you want viewstate to be pushed to behind code variables can be done here.
3	PostBackdata	Not guaranteed	Yes	Yes	You can access form data. Any logic where you want the form data to be pushed to behind code variables can be done here.
4	Load	Yes	Yes	Yes	This is the place where you will put any logic you want to operate on the controls. Like flourishing a combobox from the database, sorting data on a grid, etc. In this event, we get access to all controls, viewstate and their posted values.
5	Validate	Yes	Yes	Yes	If your page has validators or you want to execute validation for your page, this is the right place to the same.
6	Event	Yes	Yes	Yes	If this is a post back by a button click or a dropdown change, then the relative events will be fired. Any kind of logic which is related to that event can be executed here.
7	Pre-render	Yes	Yes	Yes	If you want to make final changes to the UI objects like changing tree structure or property values, before these controls are saved in to view state.
8	Save view state	Yes	Yes	Yes	Once all changes to server controls are done, this event can be an opportunity to save control data in to view state.
9	Render	Yes	Yes	Yes	If you want to add some custom HTML to the output this is the place you can.
10	Unload	Yes	Yes	Yes	Any kind of clean up you would like to do here.

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 two groups:

1. Application Life Cycle
2. Page Life Cycle

ASP.Net Application 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.

ASP.Net Page Life Cycle:

When a page is requested, it is loaded into the server memory, processed and sent to the browser. Then it is unloaded from the memory. At each of this steps, methods and events are available, which could be overridden according to the need of the application. In other words, you can write your own code to override the default code.
The Page class creates a hierarchical tree of all the controls on the page. All the components on the page, except the directives are part of this control tree. You can see the control tree by adding trace= "true" to the Page directive. We will cover page directives and tracing under 'directives' and 'error handling'.
The page life cycle phases are:

• Initialization
• Instantiation of the controls on the page
• Restoration and maintenance of the state
• Execution of the event handler codes
• Page rendering

Understanding the page cycle helps in writing codes for making some specific thing happen at any stage of the page life cycle. It also helps in writing custom controls and initializing them at right time, populate their properties with view-state data and run control behavior code.
Following are the different stages of an ASP.Net page:

• Page request . when ASP.Net gets a page request, it decides whether to parse and compile the page or there would be a cached version of the page; accordingly the response is sent
• Starting of page life cycle . at this stage, the Request and Response objects are set. If the request is an old request or post back, the IsPostBack property of the page is set to true. The UICulture property of the page is also set.
• Page initialization . at this stage, the controls on the page are assigned unique ID by setting the UniqueID property and themes are applied. For a new request postback data is loaded and the control properties are restored to the view-state values.
• Page load . at this stage, control properties are set using the view state and control state values.
• Validation . Validate method of the validation control is called and if it runs successfully, the IsValid property of the page is set to true.
• Postback event handling . if the request is a postback (old request), the related event handler is called.
• Page rendering . at this stage, view state for the page and all controls are saved. The page calls the Render method for each control and the output of rendering is written to the OutputStream class of the Page's Response property.
• Unload . the rendered page is sent to the client and page properties, such as Response and Request are unloaded and all cleanup done.

ASP.Net Page Life Cycle Events:

At each stage of the page life cycle, the page raises some events, which could be coded. An event handler is basically a function or subroutine, bound to the event, using declarative attributes like Onclick or handle.
Following are the page life cycle events:

• PreInit . PreInit is the first event in page life cycle. It checks the IsPostBack property and determines whether the page is a postback. It sets the themes and master pages, creates dynamic controls and gets and sets profile property values. This event can be handled by overloading the OnPreInit method or creating a Page_PreInit handler.
• Init . Init event initializes the control property and the control tree is built. This event can be handled by overloading the OnInit method or creating a Page_Init handler.
• InitComplete . InitComplete event allows tracking of view state. All the controls turn on view-state tracking.
• LoadViewState . LoadViewState event allows loading view state information into the controls.
• LoadPostData . during this phase, the contents of all the input fields defined with the <form> tag are processed.
• PreLoad . PreLoad occurs before the post back data is loaded in the controls. This event can be handled by overloading the OnPreLoad method or creating a Page_PreLoad handler.
• Load . the Load event is raised for the page first and then recursively for all child controls. The controls in the control tree are created. This event can be handled by overloading the OnLoad method or creating a Page_Load handler.
• LoadComplete . the loading process is completed, control event handlers are run and page validation takes place. This event can be handled by overloading the OnLoadComplete method or creating a Page_LoadComplete handler.
• PreRender . the PreRender event occurs just before the output is rendered. By handling this event, pages and controls can perform any updates before the output is rendered.
• PreRenderComplete . as the PreRender event is recursively fired for all child controls, this event ensures the completion of the pre-rendering phase.
• SaveStateComplete . state of control on the page is saved. Personalization, control state and view state information is saved. The HTML markup is generated. This stage can be handled by overriding the Render method or creating a Page_Render handler.
• UnLoad . the UnLoad phase is the last phase of the page life cycle. It raises the UnLoad event for all controls recursively and lastly for the page itself. Final cleanup is done and all resources and references, such as database connections, are freed. This event can be handled by modifying the OnUnLoad method or creating a Page_UnLoad handler.

Introduction

Just as in normal life, every ASP.Net control including Page has a life.

In our life we go through various events like Birth, Education, Marriage, Job and at the end death. And every event does some important task.

Similarly whenever a ASP.Net Page/Control is requested it goes through a sequence of events.

Before moving further I would like to put light on some important concepts.

How the request is handled by IIS

We give an URL to an aspx page in the browser address bar and press enter. What happens next? We get the response in terms of rendered HTML but how?

1. We are requesting something from the browser, which means indirectly we are requesting something from the Web Server, that means IIS. IIS, based on the file extension, decides which ISAPI extension can serve the request.
   
   And in case of ASP.Net (.aspx) it will be aspnet_isapi_dll so the request is passed to it for processing.
    
2. When the first request comes to the website,
   
   an application domain is created by the ApplicationManager class where exactly the website runs, and which creates an isolation between 2 web applications.
   Within the application domain an instance of the HostingEnvironment class is created which provides access information about the application such as the name of the folder where the application is stored.
    
3. Next ASP.Net creates core objects like HttpContext, HttpRequest,HttpResponse.
    
4. Finally the application starts by creating an instance of the HttpApplication Class (which can be reused for multiple requests to maximize performance).

Request processing by HttpApplication

While processing the request, HttpApplication invokes various events which include Module Events, handlers and Page Events.

The sequence is:

1. Module events - Important events are BeginRequest, AuthenticateRequest, AuthorizeRequest, ResolveRequestCache, AcquireRequestState and PreRequestHandlerExecute.
   We can use these events when we want to inject custom Pre-Processing logic, i.e, before Page Object is created.
   (You can read more about these events here.)
    
2. Handler Events - Once the above 6 events are fired, the ASP.NET engine will invoke the ProcessRequest event if you have implemented HttpHandler in your project. (We normally use HttpHandlers when we want to put some logic based on the file extension, such as for ImageFiles, Aspx files,...)
    
3. Page Events - After the HttpHandler logic executes the ASP.Net Page, an object is created during which various events will be fired and the important ones are
   PreInit, Init, LoadViewState, LoadPostData, Load, ControlEvents, PreRender, SaveViewState and Render.
   
   We go through every event as we move further.
    
4. Module events - Important events are PostRequestHandlerExecute, ReleaserequestState, UpdateRequestCache and EndRequest.
   We use this when we want custom Post-Processing logic.

A developer can extend any of the events as per there convenience and logic.

A small Secret about Master Pages and Life Cycle Events

Allthough Master Pages seem like a parent they are actually a child or in short we can say they behave like a user control for pages.

<%@ Page Title="My Child Page" Language="C#" MasterPageFile="~/MyMaster.master" AutoEventWireup="true" CodeFile="ChildPage.aspx.cs" Inherits=" ChildPage " %>

All events except Init and Unload fires in the manner of from the outside to the inside.
That means PageEvent will be fired first and then masterpages then the user controls and so on.
PreInit is a kind of event which exists only for Page.
Some events get executed only if it's a postback (Full/Asynchronous).

Life Cycle Events

PreInit

The properties like IsPostBack have been set at this time.

This event will be used when we want to:

1. Set master page dynamically.
2. Set theme dynamically.
3. Read or set profile property values.
4. This event is also preferred if want to create any dynamic controls.

Init

1. Raised after all the controls have been initialized with their default values and any skin settings have been applied.
2. Fired for individual controls first and then for page.

LoadViewState

1. Fires only if IsPostBack is true.
2. Values stored in HiddenField with id as _ViewState decoded and stored into corresponding controls.

LoadPostData

Some controls like:

1. Fires only if IsPostBack is true.
2. Some controls like Textbox are implemented from IPostBackDataHandler and this fires only for such controls.
3. In this event page processes postback data included in the request object pass it to the respective controls.

PreLoad

• Used only if want to inject logic before actual page load starts.

Load

• Used normally to perform tasks which are common to all requests, such as setting up a database query.

Control events

1. This event is fired when IsPostBack is true.
2. Use these events to handle specific control events, such as a Button control's Click event or a TextBox control's TextChanged event.

PreRenderRaised after the page object has created all the controls that are required for rendering which includes child controls and composite controls.

1. Use the event to make final changes to the contents of the page or its controls before the values are stored into the viewstate and the rendering stage begins.
2. Mainly used when we want to inject custom JavaScript logic.

SaveViewState

• All the control values that support viewstate are encoded and stored into the viewstate.

RenderGenerates output (HTML) to be rendered at the client side.

• We can add custom HTML to the output if we want here.

Unload

1. Fired for individual controls first and then for page.
2. Used to perform cleanup work like closing open files and database connections.