asp.net Global.asax Application File Introduction _ Practical Tips

You can use this file to implement security for your application and some other tasks. Let's take a look at how to use this file in the application development effort.

Overview

Global.asax is located in the application root directory. Although Visual Studio. NET automatically inserts this file into all ASP.net projects, it is actually an optional file. It doesn't matter if you delete it--of course, if you don't use it. The asax file name extension indicates that it is an application file, not a asp.net file that uses ASPX.

The Global.asax file is configured for any direct HTTP request (via URL) to be rejected automatically, so the user cannot download or view its contents. The ASP.net page framework automatically identifies any changes made to the Global.asax file. After the Global.asax is changed, the asp.net page framework restarts the application, including closing all browser sessions, removing all state information, and restarting the application domain.

Programming

The Global.asax file inherits from the HttpApplication class, which maintains a pool of HttpApplication objects and assigns objects from the object pool to the application when needed. The Global.asax file contains the following events:

· Application_init: This event is triggered when an application is instantiated or when it is invoked for the first time. It will be invoked for all HttpApplication object instances.

· Application_disposed: Triggers before the application is destroyed. This is the ideal place to clear previously used resources.

· Application_Error: The event is triggered when an unhandled exception is encountered in the application.

· Application_Start: The event is triggered when the first instance of the HttpApplication class is created. It allows you to create objects that can be accessed by all HttpApplication instances.

· Application_End: The event is triggered when the last instance of the HttpApplication class is destroyed. It is only triggered once in the life cycle of an application.

· Application_BeginRequest: Triggered when an application request is received. For a request, it is the first event that is triggered, and the request is typically a page request (URL) entered by the user.

· Application_EndRequest: The last event requested for the application.

· Application_prerequesthandlerexecute: The event is triggered before the ASP.net page framework starts executing an event handler such as a page or Web service.

· Application_postrequesthandlerexecute: The event is triggered when an event handler is executed at the end of the ASP.net page frame.

· Applcation_presendrequestheaders: The event is triggered when the ASP.net page frame sends an HTTP header to the requesting client (browser).

· Application_presendcontent: This event is triggered when the ASP.net page frame sends content to the requesting client (browser).

· Application_acquirerequeststate: When the asp.net page frame gets the current state (session state) associated with the current request, the event is triggered.

· Application_releaserequeststate: This event is triggered when all event handlers are executed in the ASP.net page framework. This will cause all the state modules to hold their current state data.

· Application_resolverequestcache: The event is triggered when an authorization request is completed on the ASP.net page frame. It allows caching modules to service requests from the cache, bypassing the execution of event handlers.

· Application_updaterequestcache: When the asp.net page framework completes execution of an event handler, the event is triggered so that the cache module stores the response data for use in response to subsequent requests.

· Application_AuthenticateRequest: This event is triggered when the security module establishes a valid identity for the current user. At this point, the user's credentials will be validated.

· Application_authorizerequest: The event is triggered when the security module confirms that a user can access the resource.

· Session_Start: The event is triggered when a new user accesses the application Web site.

· Session_End: This event is triggered when a user's session times out, ends, or when they leave the application Web site.

This list of events may seem intimidating, but these events can be very useful in different contexts.

One of the key issues in using these events is to know the order in which they are triggered. The Application_init and Application_Start events are triggered once the application is first started. Similarly, application_disposed and Application_End events are triggered once when the application terminates. In addition, session-based events (Session_Start and session_end) are used only when the user enters and leaves the site. The remaining events handle application requests, which are triggered in the following order:

· Application_BeginRequest

· Application_AuthenticateRequest

· Application_authorizerequest

· Application_resolverequestcache

· Application_acquirerequeststate

· Application_prerequesthandlerexecute