The global.asax file is the ASP.Net counterpart of the global.asa file used in traditional ASP Applications. This file is the placeholder for code to respond to application level events raised in ASP.Net or by HTTP modules. The global.asax file resides in the root directory of an ASP.Net application.
Note that the global.asax file is optional and required only if you want to define application or session event handlers.
When you save any changes to the global.asax file, the ASP.Net framework effectively reboots the application, closing all browser sessions and flushing all state information for that application domain. The Application_OnStart event is triggered when the next request arrives.
We will now go through the possible contents of the global.asax file.
1. Application Directives
These are optional settings used by the ASP.Net processor.
@Application Directive
<%@ Application attribute=”value” [attribute=value ]%>
Example: <%@ Application Inherits=”TestApp.Object” Description=”Our Test app” %>
The code above instructs the compiler to compile a new application class that extends the TestApp.Object class
@Import Directive
<%@ Import namespace=”value” %>
Example: <%@ Import Namespace=”System.IO” %>
The code above instructs the compiler to include the System.IO namespaces from the .Net Framework.
You must indicate a separate Import directive for each namespace you want to import.
@Assembly Directive
<%@ Assembly name=”value” %>
Example: <%@ Assembly Name=”TestAssembly.dll” %>
Including this directive will allow the compiler to reference the assembly for early binding and load the assembly in the application domain once the compilation of the requested page is complete, to allow late binding. Assemblies that reside in the application’s Bin folder do not require the @Assembly directive.
2. Code Declaration blocks
You can use the global.asax file to override any event that is exposed by the HttpApplication base class. This is the generic format used to override application or session events:
<script runat=”server” language=”language” [src=”externalfile”]>
Object_EventName(AppropriateEventArgumentSignature)
</script>
Here is a list of Applications and Session events available for overriding in ASP.Net
Application_Init: This method is invoked on all HttpApplication instances within an application. You can include initialization code for the application here.
Application_Disposed: This method is invoked on all HttpApplication instances before destroying an instance. You can clean up any local resources in this method.
Application_Error: This event occurs when an unhandled exception is thrown
Application_Start: This event is invoked on the first instance of the HttpApplication only once during the lifetime of the application. You can use this event to create objects that are shared by all instances. Do not create local variables in this event, as local variables are not shared by multiple HttpApplication instances. If you have used the traditional ASP global.asa, you must have already come across a similar function before.
Application_End: This event is raised only once in an Application s lifetime, on the last instance of HttpApplication that is destroyed. You can use this event to clean up shared resource or states and not local variables.
Application_BeginRequest: This event occurs as the first event when ASP.Net responds to a request.
Application_EndRequest: This event occurs as the last event when ASP.Net responds to a request.
Application_PreRequestHandlerExecute: This event occurs just before ASP.Net begins executing a handler such as a page or a web service. At this point, the session state is available.
Application_PostRequestHandlerExecute: This event occurs when the ASP.Net handler finishes execution.
Application_PreSendRequestHeaders: This event occurs just before ASP.Net sends HTTP Headers to the client.
Application_PreSendRequestContent: This event occurs just before ASP.Net sends content to the client.
Application_AcquireRequestState: This event occurs when ASP.Net acquires the current state (eg. Session state) associated with the current request.
Application_ReleaseRequestState: This event occurs after ASP.NET finishes executing all request handlers. This event causes state modules to save the current state data.
Application_ResolveRequestCache: This event occurs when ASP.Net completes an authorization event to let the caching modules serve the request from the cache bypassing the execution of the handler. This improves the performance of the web site and this event can be used to judge if the contents are used from the cache or not.
Application_UpdateRequestCache: This event occurs when ASP.Net finishes executing a handler in order to let caching modules store responses that will be used to serve subsequent requests from the cache.
Application_AuthenticateRequest: This event occurs when the security module has established that the identity of the current user is valid. At this point the user’s credentials have been validated.
Application_AuthorizeRequest: This event occurs when the security module has verified user is authorized to access the resources.
Session_Start: This event is triggered when any new user accesses the web site.
Session_End: This event is triggered when a user’s session times out or ends.
Here is the order in which the Application events are triggered:
– BeginRequest
– AuthenticateRequest
– AuthorizeRequest
– ResolveRequestCache
– AcquireRequestState
– PreRequestHandlerExecute
– PreSendRequestHeaders
– PreSendRequestContent
– (actual processing)
– PostRequestHandlerExecute
– ReleaseRequestState
– UpdateRequestCache
– EndRequest
3. Server side Object Tags
The <object> tag can be used to create global application or session objects in the ASP.Net Application.
<object id=”id” runat=”server” scope=”scope” class=”Class Name of .Net Framework object”>
<object id=”id” runat=”server” scope=”scope” progid=”ProgID of COM component”/>
<object id=”id” runat=”server” scope=”scope” classid=”ClassID of COM component”/>
Example: <object id=”SelectedProducts” class=”SomeDotNetClass” runat=”server”/>
The scope of the object created in this way can have the following values:
– Pipeline: indicates that the object is available only to the HTTP request for the containing the ASP.Net application file. This is the default value.
– Application: the object is populated in the HttpApplicationState object.
– Session: the object is populated in the HttpSession object.
4. Server side Include Directives
These statements can be included in global.asax or any ASP.Net file. This directive causes the contents of the specified file to be included into the file containing the directive.
<!– #include pathtype = filename –>
Pathtype can be have the following values:
– Virtual: indicates that the filename parameter is a virtual path.
– File: indicates that the filename parameter is a relative path from the directory containing the file with the #include directive.
Conclusion
We discussed in this article that global.asax is the central driving point of the ASP.Net application. We learnt how to include common compiler directives in the global.asax file. We saw how to handle application and session events triggered during the course of the ASP.Net application life cycle. These events are very important as they give us an insider point in tackling many aspects of the ASP.Net application. We also saw how to define global objects in ASP.Net in the global.asax file and the syntax to include external files within the global.asax application file.
Dipal Choksi is a Bachelor of Engineering (Computer Science). She has industry experience in team-effort projects and also as an individual contributor. She has worked on Visual Basic, Visual C++, Java, Directory Services, ASP projects
