Definition by Microsoft: The Global.asax file, also known as the ASP.NET application file, is an optional file that contains code for responding to application-level and session-level events raised by ASP.NET or by HTTP modules. The Global.asax file resides in the root directory of an ASP.NET application. At run time, Global.asax is parsed and compiled into a dynamically generated .NET Framework class derived from the HttpApplication base class. ASP.NET is configured so that any direct URL request for the Global.asax file is automatically rejected; external users cannot download or view the code in it.

Defintion by Wiki: Global.asax is an optional file used to declare and handle application- and session-level events and objects. Global.asax is the ASP.NET extension of the ASP Global.asa file. The Global.asax file resides in the IIS virtual root of an ASP.NET application. At run time, upon the arrival of the first request, Global.asax is parsed and compiled into a dynamically generated .NET Framework class. ASP.NET is configured so that any direct request for the Global.asax is automatically rejected, external users cannot view or download the code in it. [1] Code to handle application events (such as the start and end of an application) resides in Global.asax. Such event code cannot reside in the ASP.NET page or web service code itself, since during the start or end of the application, its code has not yet been loaded (or unloaded). Global.asax is also used to declare data that is available across different application requests or across different browser sessions. This process is known as application and session state management. The Global.asax file must reside in the IIS virtual root. Remember that a virtual root can be thought of as the container of a web application. Events and state specified in the global file are then applied to all resources housed within the web application. If, for example, Global.asax defines a state application variable, all .aspx files within the virtual root will be able to access the variable. The ASP.NET Global.asax file can coexist with the ASP Global.asa file. You can create a Global.asax file either in a WYSIWYG designer or as a compiled class that you deploy in your application's \Bin directory as an assembly. However, in the latter case, you still need a Global.asax file that refers to the assembly. Like an ASP.NET page, the Global.asax file is compiled upon the arrival of the first request for any resource in the application. The similarity continues when changes are made to the Global.asax file: ASP.NET automatically notices the changes, recompiles the file, and directs all new requests to the newest compilation.

The Global.asax file is optional. You create it only if you want to handle application or session events.

Useful Events in Global.asax: 1. 2. 3. 4. 5. 6. 7. 8. 9. Application_Init Application_Start Session_Start Application_BeginRequest Application_EndRequest Application_AuthenticateRequest Application_Error Session_End Application_End

Application_Init: The Application_Init event is fired when an application initializes the first time. Application_Start: The Application_Start event is fired the first time when an application starts. Session_Start: The Session_Start event is fired the first time when a user’s session is started. This typically contains for session initialization logic code. Application_BeginRequest: The Application_BeginRequest event is fired each time a new request comes in. Application_EndRequest: The Application_EndRequest event is fired when the application terminates. Application_AuthenticateRequest: The Application_AuthenticateRequest event indicates that a request is ready to be authenticated. If you are using Forms Authentication, this event can be used to check for the user's roles and rights. Application_Error: The Application_Error event is fired when an unhandled error occurs within the application. Session_End: The Session_End Event is fired whenever a single user Session ends or times out. Application_End: The Application_End event is last event of its kind that is fired when the application ends or times out. It typically contains application cleanup logic.

Format of the global.asax file preset in ASP.NET
<%@ Application Language="C#" %> <script runat="server"> void Application_Start(object sender, EventArgs e) { // Code that runs on application startup } void Application_End(object sender, EventArgs e) { // Code that runs on application shutdown } void Application_Error(object sender, EventArgs e) { // Code that runs when an unhandled error occurs } void Session_Start(object sender, EventArgs e) { // Code that runs when a new session is started } void Session_End(object sender, EventArgs e) { // Code that runs when a session ends. // Note: The Session_End event is raised only when the sessionstate mode // is set to InProc in the Web.config file. If session mode is set to StateServer // or SQLServer, the event is not raised. } </script>

Events in Global.asax File The Global.asax file, which is derived from the HttpApplication class, maintains a pool of HttpApplication objects, and assigns them to applications as needed. The Global.asax file contains the following events: Application_Init: Fired when an application initializes or is first called. It is invoked for all HttpApplication object instances. Application_Disposed: Fired just before an application is destroyed. This is the ideal location for cleaning up previously used resources Application_Error: Fired when an unhandled exception is encountered within theapplication. Application_Start: Fired when the first instance of the HttpApplication class is created.It allows you to create objects that are accessible by all HttpApplication instances. Application_End: Fired when the last instance of an HttpApplication class is destroyed.It is fired only once during an application's lifetime. Application_BeginRequest: Fired when an application request is received. It is the first event fired for a request, which is often a page request (URL) that a user enters. Application_EndRequest: The last event fired for an application request.

Application_PreRequestHandlerExecute: Fired before the ASP.NET page framework begins executing an event handler like a page or Web service. Application_PostRequestHandlerExecute: Fired when the ASP.NET page framework has finished executing an event handler. Applcation_PreSendRequestHeaders: Fired before the ASP.NET page framework sends HTTP headers to a requesting client (browser). Application_PreSendContent: Fired before the ASP.NET page framework send content to a requesting client (browser). Application_AcquireRequestState: Fired when the ASP.NET page framework gets the current state (Session state) related to the current request. Application_ReleaseRequestState: Fired when the ASP.NET page framework completes execution of all event handlers. This results in all state modules to save their current state data. Application_ResolveRequestCache: Fired when the ASP.NET page framework completes an

authorization request. It allows caching modules to serve the request from the cache, thus bypassing handler execution. Application_UpdateRequestCache: Fired when the ASP.NET page framework completes handler execution to allow caching modules to store responses to be used to handle subsequent requests. Application_AuthenticateRequest: Fired when the security module has established the current user's identity as valid. At this point, the user's credentials have been validated. Application_AuthorizeRequest: Fired when the security module has verified that a user can access resources. Session_Start: Fired when a new user visits the application Web site. Session_End: Fired when a user's session times out, ends, or they leave the application Web site.

Setting Up Global global.asax File




ASP.NET uses a special file, calledglobal.asax, to establish any global objects that your Web applicationuses. The .asax extension denotes an application file rather than .aspxfor a page file. Each ASP.NET application can contain atmost one global.asax file. The file is compiled on the first page hitto your Web application. ASP.NET is also configured so that anyattempts to browse to the global.asax page directly are rejected. Listing 3.8 shows a global.asax file that you can use to make a more complete hit counter. Listing 3.8 global.asax: Event Handlers for the Application and Session Objects 1: <%@ language="C#" %> 2: <script runat="server"> 3: void Application_Start(Object Sender, EventArgs e) 4: { 5: Application["Hits"] = 0; 6: Application["Sessions"] = 0;

7: Application["TerminatedSessions"] = 0; 8: } 9: 10: //The BeginRequest event is fired for every hit to every page in the site 11: void Application_BeginRequest(Object Sender, EventArgs e) 12: { 13: Application.Lock(); 14: Application["Hits"] = (int) Application["Hits"] + 1; 15: Application.UnLock(); 16: } 17: void Session_Start(Object Sender, EventArgs e) 18: { 19: Application.Lock(); 20: Application["Sessions"] = (int) Application["Sessions"] + 1; 21: Application.UnLock(); 22: } 23: 24: void Session_End(Object Sender, EventArgs e) 25: { 26: Application.Lock(); 27: Application["TerminatedSessions"] = 28: (int) Application["TerminatedSessions"] + 1; 29: Application.UnLock(); 30: } 31: 32: void Application_End(Object Sender, EventArgs e) 33: { 34: //Write out our statistics to a log file 35: //…code omitted… 36: } 37: </script> The global.asax file in Listing 3.8 contains event handlers for the Session and Application objects. Each event handler has the same signature as the Page_Load event handler. The code in Listing 3.8 handles three Application object-related events: Start (Lines 3-8), End (Lines 24-30), and BeginRequest (Lines 11-16). Start and End are called when the Web application starts and ends, respectively. BeginRequest is called for every page hit that the site receives. Listing 3.8 updates the total number of hits on this event. The Session Start (Lines 17-22) and End(Lines 24-30) events are handled in the middle of the listing. Thesetwo events count how many different Web users have accessed the site. You can write a simple page to utilize the statistics that Listing 3.8 tracks. Listing 3.9 shows a page that writes out the results of the hit-counting code


Figure 3.5 Figure 3.5 shows the Statistics page after a few hits. Listing 3.9 Statistics.aspx: The Results of the Tracking in the global.asax File <%@ page language="C#" %> <html> <body> <h2> Statistics for the Test Web Application </h2> Total hits: <% Response.Write(Application["Hits"].ToString()); %> <br> Total sessions: <% Response.Write(Application["Sessions"].ToString()); %> <br> Expired sessions: <% Response.Write(Application["TerminatedSessions"].ToString()); %> <br> </body> </html> TIP If the global.asax file is modified, theWeb application is restarted on the next page hit, and the global.asaxfile is recompiled. Figure 3.5 The Statistics page after some traffic.

Adding Objects to the global.asax File

To use global objects in your ASP.NET application, add the <object> tag in the global.asax file for each one. The <object> tag has an optional attribute called scope, which determines if the added object will be created on-the-fly, associated with the Application object, or associated with the Session object. To explore the <object> tag,let's create a simple class that stores and retrieves strings. Thesample is going to associate an object of this class with the Application object in the global.asax file, so the class must be thread-safe. The term thread-safemeans that many client threads can access the class at the same timewithout any data corruption. Because ASP.NET uses one thread per page,ensuring that the class is thread-safe is critical if multiple usersbrowse the site at the same time. Understanding Threads What's a thread? To answer, let's review processesfirst. All Windows applications are processes that run on yourcomputer. Processes contain their own code and memory space, and caninteract with computer peripherals, such as the screen or the networkcard. ASP.NET runs as a process, and it executes your code, of course. Each process contains one or many threads. A threadis like a process or an individual program because it also executes acertain set of code. However, a thread is a "lightweight" version of aprocess. Threads live inside processes and use a process' memory. TheWindows operating system gives each thread a small amount of time toexecute and quickly switches between threads so that it seems like morethan one thread is executing at the same time. For all practicalintents, the threads are running at the same time. Because threads use their parent process'memory, they can potentially change the same object (in memory) at thesame time. For two threads, A and B, thread A might add 10 to a counterobject. Thread B might subtract 10 from the counter. If the two threadsare switched on and off by the operating system in an "unlucky" way,the counter object could contain a scrambled result. Each ASP.NET page, when it is beingprocessed, gets its own thread. If more than one user uses the Web siteat the same time, many threads will appear, even if both users areaccessing the same ASP.NET page. To prevent threads (and ASP.NET pages) frominterfering with each other when accessing the same object, use thetechnique in the example that follows. To make the class thread-safe, use the Synchronized method of the base collection class, Hashtable. This class is shown in Listing 3.10. Listing 3.10 MyClass.cs: Implementing a Class to Store and Retrieve Strings in a Thread-Safe Way

using System; using System.Collections; namespace TestApplication { public class MyClass { private Hashtable m_col; //m_colSync will be a thread-safe container for m_col private Hashtable m_colSync; public MyClass() { m_col = new Hashtable(); m_colSync = Hashtable.Synchronized(m_col); } public void AddItem(String Name, String Value) { m_colSync[Name] = Value; } public String GetItem(String Name) { return (String) m_colSync[Name]; } } } //note: use "csc /out:bin\myclass.dll // to compile with the command line utility /t:library myclass.cs /r:system.dll"

The next step is to add this object to the global.asax file with the <object> tag. A short global.asax file that does this follows: <object id="StringCollection" class="TestApplication.MyClass" scope="Application" /> runat="server"

The id attribute tells ASP.NET what to call our object when it's used later. The class attribute can be used to specify COM objects in addition to .NET components, but by using their ProgID. If the listing omitted the scope attribute, a new object is created on-the-fly for every page that uses the StringCollection object. Let's write a sample page that uses StringCollection. Listing 3.11 shows just such a page. Listing 3.11 UseObject.aspx: Using the Global Object <%@ language="C#" %> <script runat="server">

void Page_Load(Object Sender, EventArgs e) { StringCollection.AddItem("FirstUser", "Joe Smith"); } </script> <html> <body> The name of the first user is <% Response.Write(StringCollection.GetItem("FirstUser")); %> </body> </html>

Putting Code Behind the global.asax File
If you use Visual Studio.NET to create yourWeb project, it will use the code behind feature of ASP.NET forglobal.asax. The code behind file that is generated is namedglobal.asax.cs, when using the C# compiler. To use code behind inglobal.asax manually, use the Application directive instead of the Page directive, like this: <@ Application Inherits="MyApplication.GlobalClass" %> Listing 3.12 shows a code behind example for the global.asax file. Listing 3.12 GlobalClass.cs: Implementing the Code for the global.asax File namespace MyApplication { using System; using System.Web; using System.Web.SessionState; public class GlobalClass : System.Web.HttpApplication { protected void Session_Start(Object Sender, EventArgs e) { Response.Write("Session started <br>"); } } } //note: use "csc /out:bin\globalclass.dll /t:library globalclass.cs /r:system.dll" // to compile with the command line utility TIP You can mix code behind and the <object> tag in the global.asax file.

Sign up to vote on this title
UsefulNot useful