Introduction to Asp.Net Page Life Cycle

In this example, I am trying to help you to give fair ideas about the life cycle of ASP.NET Page.

Following are the steps which occur when we request an ASPX page: -

The browser sends the request to the web server. Let’s assume that the web server at the other end is IIS. Once IIS receives the request he looks on which engine can serve this request.

When I mean engine means the DLL who can parse this page or compile and send a response back to browser. Which request to map to be decided by file extension of the page requested.

Depending on file extension following are some mapping

1. .aspx, for ASP.NET Web pages
2. .asmx, for ASP.NET Web services
3. .config, for ASP.NET configuration files
4. .ashx, for custom ASP.NET HTTP handlers
5. .rem, for remoting resources etc.

 

You can also configure the extension mapping to which engine it can route by using the IIS engine.

Example an ASP page will be sent to old classic ASP.DLL to compile. While .ASPX pages will be routed to ASP.NET engine for compilation.

As this article mainly will target ASP.NET we will look in to how ASP.NET pages that is ASPX pages generation sequence occurs. Once IIS passes the request to ASP.NET engine page has to go through two section HTTP module section and HTTP handler section. Both these section have there own work to be done in order that the page is properly compiled and sent to the IIS. HTTP modules inspect the incoming request and depending on that they can change the internal workflow of the request. HTTP handler actually compiles the page and generates output. If you see your machine.config file you will see following section of HTTP modules

Can you explain in brief how the ASP.NET authentication process works?

ASP.NET does not run by itself it runs inside the process of IIS. So there are two authentication layers which exist in ASP.NET system. First authentication happens at the IIS level and then at the ASP.NET level depending on the WEB.CONFIG file.

Below is how the whole process works:-

IIS first checks to make sure the incoming request comes from an IP address that is allowed access to the domain. If not it denies the request.

 

Next IIS performs its own user authentication if it is configured to do so. By default IIS allows anonymous access, so requests are automatically authenticated, but you can change this default on a per – application basis with in IIS

If the request is passed to ASP.Net with an authenticated user, ASP.Net checks to see whether impersonation is enabled. If impersonation is enabled, ASP.Net acts as though it were the authenticated user. If not ASP.Net acts with its own configured account.

Finally the identity from step 3 is used to request resources from the operating system. If ASP.Net authentication can obtain all the necessary resources it grants the users request otherwise it is denied. Resources can include much more than just the ASP.Net page itself you can also use .Net’s code access security features to extend this authorization step to disk files, Registry keys and other resources.

Asp.Net Page Life Cycle:

When a page request is sent to the Web server, whether through a submission or location change, the page is run through a series of events during its creation and disposal. The page is loaded for the first time and has several server-side Web controls on it. When the Web server receives a request for the page, it will process our Web controls and we will eventually get rendered HTML. The first step in processing our page is object initialization.

1. Initialization() –oninit()  :   Controls are initialized based on their declaration as in the constructor but with no properties or attributes. So it is dangerous to access them through code

2. LoadViewState() : At the end of this phase, the ViewState property of a control is automatically populated. At LoadViewState event, the initialized controls receive their first properties: viewstate information that was persisted back to the server on the last submission

3. LoadPostData() : Loading ……Now the Server process incoming form data and update properties accordingly.  During this phase of the page creation, form data that was posted to the server is processed against each control that requires it.ie updates the control state with the correct postback data.Loaded…….

4. Load ()– OnLoad():  At this point, all controls in the server are updated with client control’s data Objects can be referenced easily through code or relative position.

5. RaisePostDataChanged(): Send postback change notifications

The RaisePostDataChanged event does not fire until all controls are updated and after the Load event has occurred. This ensures data in another control is not manually altered during the RaisePostDataChanged event before it is updated with postback data

6. RaisePostBackEvent Handle postback events.

Handle the client-side event that caused the postback and raise appropriate events on the server

7. PreRender – onPreRender()

The point at which the objects are prerendered is the last time changes to the objects can be saved or persisted to viewstate. This makes the PreRender step a good place to make final modifications, such as changing properties of controls or changing Control Tree structure, without having to worry about ASP.NET making changes to objects based off of database calls or viewstate updates. After the PreRender phase those changes to objects are locked in and can no longer be saved to the page viewstate. The PreRender step can be overridden using OnPreRender

8. ViewState Saved: The viewstate is saved after all changes to the page objects have occurred. Object state data is persisted in the hidden object and this is also where object state data is prepared to be rendered to HTML. At the SaveViewState event, values can be saved to the ViewState object, but changes to page controls are not

9. Render to HTML: The Render event commences the building of the page by assembling the HTML for output to the browser. During the Render event, the page calls on the objects to render them into HTML. The page then collects the HTML for delivery. When the Render event is overridden, the developer can write custom HTML to the browser that nullifies all the HTML the page has created thus far. The Render method takes an HtmlTextWriter object as a parameter and uses that to output HTML to be streamed to the browser. Changes can still be made at this point, but they are reflected to the client only.

1. Object Initialization:

A page’s controls (and the page itself) are first initialized in their raw form. By declaring your objects within the constructor of your C# code-behind file (see Figure 1), the page knows what types of objects and how many to create. Once you have declared your objects within your constructor, you may then access them from any sub class, method, event, or property. However, if any of your objects are controls specified within your ASPX file, at this point the controls have no attributes or properties. It is dangerous to access them through code, as there is no guarantee of what order the control instances will be created (if they are created at all). The initialization event can be overridden using the OnInit method.

2. Load Viewstate Data:

After the Init event, controls can be referenced using their IDs only (no DOM is established yet for relative references). At LoadViewState event, the initialized controls receive their first properties: viewstate information that was persisted back to the server on the last submission. The page viewstate is managed by ASP.NET and is used to persist information over a page roundtrip to the server. Viewstate information is saved as a string of name/value pairs and contains information such as control text or value. The viewstate is held in the value property of a hidden control that is passed from page request to page request. As you can see, this is a giant leap forward from the old ASP 3.0 techniques of maintaining state. This event can be overridden using the LoadViewState method and is commonly used to customize the data received by the control at the time it is populated.

3. LoadPostData()  - Processes Postback Data

Now the Server process incoming form data and update properties accordingly.

During this phase of the page creation, form data that was posted to the server (termed postback data in ASP.NET) is processed against each control that requires it. When a page submits a form, the framework will implement the IPostBackDataHandler interface on each control that submitted data. The page then fires the LoadPostData event and parses through the page to find each control that implements this interface and updates the control state with the correct postback data. ASP.NET updates the correct control by matching the control’s unique ID with the name/value pair in the NameValueCollection. This is one reason that ASP.NET requires unique IDs for each control on any given page. Extra steps are taken by the framework to ensure each ID is unique in situations, such as several custom user controls existing on a single page.  After the LoadPostData event triggers, the RaisePostDataChanged event is free to execute.

4. Object Load

Objects take true form during the Load event. All objects are first arranged in the page DOM (called the Control Tree in ASP.NET) and can be referenced easily through code or relative position (crawling the DOM). Objects are then free to retrieve the client-side properties set in the HTML, such as width, value, or visibility. During Load, coded logic, such as arithmetic, setting control properties programmatically, and using the StringBuilder to assemble a string for output, is also executed. This stage is where the majority of work happens. The Load event can be overridden by calling OnLoad.

5. Raise PostBack Change Events

After updating controls with the correct postback data.,this event is raised. As stated earlier, this occurs after all controls that implement the IPostBackDataHandler interface have been updated with the correct postback data. During this operation, each control is flagged with a Boolean on whether its data was actually changed or remains the same since the previous submit. ASP.NET then sweeps through the page looking for flags indicating that any object’s data has been updated and fires RaisePostDataChanged. The RaisePostDataChanged event does not fire until all controls are updated and after the Load event has occurred. This ensures data in another control is not manually altered during the RaisePostDataChanged event before it is updated with postback data.

6. Process Client-Side PostBack Event

After the server-side events fire on data that was changed due to postback updates, the object which caused the postback is handled at the RaisePostBackEvent event. The offending object is usually a control that posted the page back to the server due to a state change (with autopostback enabled) or a form submit button that was clicked. There is often code that will execute in this event, as this is an ideal location to handle event-driven logic. The RaisePostBackEvent event fires last in the series of postback events due to the accuracy of the data that is rendered to the browser.

Controls that are changed during postback should not be updated after the executing function is called due to the consistency factor. That is, data that is changed by an anticipated event should always be reflected in the resulting page.

7. Prerender the Objects

The point at which the objects are prerendered is the last time changes to the objects can be saved or persisted to viewstate. This makes the PreRender step a good place to make final modifications, such as changing properties of controls or changing Control Tree structure, without having to worry about ASP.NET making changes to objects based off of database calls or viewstate updates. After the PreRender phase those changes to objects are locked in and can no longer be saved to the page viewstate. The PreRender step can be overridden using OnPreRender.

8. ViewState Saved

The viewstate is saved after all changes to the page objects have occurred. Object state data is persisted in the hidden object and this is also where object state data is prepared to be rendered to HTML. At the SaveViewState event, values can be saved to the ViewState object, but changes to page controls are not.

9. Render to HTML

The Render event commences the building of the page by assembling the HTML for output to the browser. During the Render event, the page calls on the objects to render them into HTML. The page then collects the HTML for delivery. When the Render event is overridden, the developer can write custom HTML to the browser that nullifies all the HTML the page has created thus far. The Render method takes an HtmlTextWriter object as a parameter and uses that to output HTML to be streamed to the browser. Changes can still be made at this point, but they are reflected to the client only.

10. Disposal

After the page’s HTML is rendered, the objects are disposed of. During the Dispose event, you should destroy any objects or references you have created in building the page. At this point, all processing has occurred and it is safe to dispose of any remaining objects, including the Page object.