ASP.NET Application Life Cycle Events and Global.asax

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, we can create a file named Global.asax in the root directory of your application.

If we 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.

The Application_Start and Application_End methods are special methods that do not represent HttpApplication events. ASP.NET calls them once for the lifetime of the application domain, not for each HttpApplication instance.

Below is the commonly used events and methods during the application life cycle :-

1)Application_Start :-  

Called when the first resource (such as a page) in an ASP.NET application is requested. The Application_Start method is called only one time during the life cycle of an application.

You can use this method to perform startup tasks such as loading data into the cache and initializing static values.You should set only static data during application start. Do not set any instance data because it will be available only to the first instance of theHttpApplication class that is created.

 

2) Application_event :-

Raised at the appropriate time in the application life cycle.
Application_Error can be raised at any phase in the application life cycle.
Application_EndRequest  is the only event that is guaranteed to be raised in every request, because a request can be short-circuited.

3)Init :- 

Called once for every instance of the HttpApplication class after all modules have been created.

4) 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.

5) Application_End :-

Called once per lifetime of the application before the application is unloaded.

 
Reference :- http://msdn.microsoft.com/en-us/library/ms178473(v=vs.100).aspx

 

Programming is Easy…..

ASP.NET Application Life Cycle

ASP.NET Application Life Cycle  Overview for IIS 5.0 and 6.0 are divided in below stages:-

Stage 1:-  User requests an application resource from the Web server

The life cycle of an ASP.NET application starts with a request sent by a browser to the Web server.  ASP.NET is an ISAPI extension under the Web server. When a Web server receives a request, it examines the file-name extension of the requested file, determines which ISAPI extension should handle the request, and then passes the request to the appropriate ISAPI extension. ASP.NET handles file name extensions that have been mapped to it, such as .aspx, .ascx, .ashx, and .asmx.

NoteNote : If a file name extension has not been mapped to ASP.NET, ASP.NET will not receive the request. This is important to understand for applications that use ASP.NET authentication. For example, because .htm files are typically not mapped to ASP.NET, ASP.NET will not perform authentication or authorization checks on requests for .htm files. Therefore, even if a file contains only static content, if you want ASP.NET to check authentication, create the file using a file name extension mapped to ASP.NET, such as .aspx.

Stage 2 :- ASP.NET receives the first request for the application.

When ASP.NET receives the first request for any resource in an application, a class named ApplicationManager creates an application domain.  Application domains provide isolation between applications for global variables and allow each application to be unloaded separately. Within an application domain, an instance of the class named HostingEnvironment is created, which provi;-des access to information about the application such as the name of the folder where the application is stored.

The following diagram illustrates this relationship:

 

Stage 3:- ASP.NET core objects are created for each request

After the application domain has been created and the HostingEnvironment object instantiated, ASP.NET creates and initializes core objects such as HttpContextHttpRequest, and HttpResponse. 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, including cookies and browser information. The HttpResponse object contains the response that is sent to the client, including all rendered output and cookies.

 

Stage 4:- An HttpApplication object is assigned to the request

After all core 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 and uses the derived class to represent the application.

 

NoteNote :- The first time an ASP.NET page or process is requested in an application, a new instance of HttpApplication is created. However, to maximize performance, HttpApplication instances might be reused for multiple requests.
Stage 5:-  The request is processed by theHttpApplication pipeline
The following events are executed by the HttpApplication class while the request is processed. The events are of particular interest to developers who want to extend the HttpApplication class.

  1. 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.
  2. Perform URL mapping, if any URLs have been configured in the UrlMappingsSection section of the Web.config file.
  3. Raise the BeginRequest event.
  4. Raise the AuthenticateRequest event.
  5. Raise the PostAuthenticateRequest event.
  6. Raise the AuthorizeRequest event.
  7. Raise the PostAuthorizeRequest event.
  8. Raise the ResolveRequestCache event.
  9. Raise the PostResolveRequestCache event.
  10. Based on the file name extension of the requested resource (mapped in the application’s configuration file), select a class that implementsIHttpHandler 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 the page before creating an instance of it.
  11. Raise the PostMapRequestHandler event.
  12. Raise the AcquireRequestState event.
  13. Raise the PostAcquireRequestState event.
  14. Raise the PreRequestHandlerExecute event.
  15. 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.
  16. Raise the PostRequestHandlerExecute event.
  17. Raise the ReleaseRequestState event.
  18. Raise the PostReleaseRequestState event.
  19. Perform response filtering if the Filter property is defined.
  20. Raise the UpdateRequestCache event.
  21. Raise the PostUpdateRequestCache event.
  22. Raise the EndRequest event.
  23. Raise the PreSendRequestHeaders event.
  24. Raise the PreSendRequestContent event.
Programming is Easy….

ASP.NET MVC request lifecycle

jogendra@.net

All ASP.NET MVC application life cycle starts out like any other website application: with a request to a
URL.

Routing :- ASP.NET Routing framework is at the core of every ASP.NET MVC request.
In simple terms, ASP.NET routing is just a pattern-matching system. At startup,
the application registers one or more patterns with the framework’s route table to tell
the routing system what to do with any requests that match those patterns. When the
routing engine receives a request at runtime, it matches that request’s URL against the
URL patterns registered with it.

When the routing engine finds a matching pattern in its route table, it forwards the
request to the appropriate handler for that request.
Otherwise, when the request’s URL does not match any of the registered route patterns,
the routing engine indicates that it could not figure out how to handle the request by
returning a 404 HTTP…

View original post 2 more words