Global directives, also known as application directives, provide application-wide instructions to the ASP.NET compilation engine. A Global.asax file supports three types of global directives:

• @ Application directives

• @ Import directives

• @ Assembly directives

Global.asax can contain just one @ Application directive, but it places no limit on the number of @ Import and @ Assembly directives.

<%@ Application Description="My First ASP.NET Application" %>

<%@ Import Namespace="System.Data" %>

<script language="C#" runat="server">
  void Application_Start ()
  {
      DataSet ds = new DataSet ();
      ds.ReadXml (Server.MapPath ("GlobalData.xml"));
      Application["GlobalData"] = ds;
  }
</script>

using System.Web;
using System.Data;

public class MyApp : HttpApplication
{
    public void Application_Start ()
    {
        DataSet ds = new DataSet ();
        ds.ReadXml ("GlobalData.xml");
        Application["GlobalData"] = ds;
    }
}

<%@ Application Inherits="MyApp" %>

<script language="C#" runat="server">
  void Application_Start ()
  {
      DataSet ds = new DataSet ();
      ds.ReadXml (Server.MapPath ("GlobalData.xml"));
      Application["GlobalData"] = ds;
  }
</script>

<%@ Import Namespace="System.Data" %>

<%@ Import Namespace="System.DirectoryServices" %>
<%@ Assembly Name="System.DirectoryServices" %>

The most common reason for including Global.asax files in ASP.NET applications is to handle global events—events that aren’t specific to a particular page but that apply to the application as a whole. Some global events are fired by the HttpApplication instances that process individual requests. Others are fired by HTTP modules—plug-in components that provide services such as authentication and output caching to ASP.NET. Some events fire on every request. Others fire at predictable junctures in an application’s lifetime, such as when the application starts or stops. Still others fire conditionally—for example, when an unhandled exception occurs. Regardless of when a global event fires or who fires it, you can process it by including a handler in Global.asax.

ASP.NET fires global events named Start and End when an application starts and stops. To process these events, include handlers named Application_Start and Application_End in Global.asax:

<script language="C#" runat="server">
  void Application_Start ()
  {
    ...
  }

  void Application_End ()
  {
    ...
  }
</script>

Application_Start is called when the application receives its first request. This handler is frequently used to initialize application state or the ASP.NET application cache (both of which are introduced later in this chapter) with data that is global to the application—that is, shared by all of its users. Application_End is called when the application shuts down. Typically, that happens when the application has run for 20 minutes without receiving an HTTP request. Application_End isn’t used all that often because ASP.NET applications don’t have to clean up after themselves by deleting objects created in Application_Start, but it’s sometimes used to write data to a persistent storage medium prior to shutdown so that the data can be reloaded the next time the application starts and to dispose of objects that encapsulate unmanaged resources such as database connections.

Later in this chapter, you’ll learn about ASP.NET session state. Session state is a mechanism for storing per-user information (such as shopping carts) in Web applications and preserving it across requests. Session state services are provided by an HTTP module named SessionStateModule, which fires a Start event each time it creates a session and an End event each time a session ends. You can process these events by including handlers named Session_Start and Session_End in Global.asax:

<script language="C#" runat="server">
  void Session_Start ()
  {
    ...
  }

  void Session_End ()
  {
    ...
  }
</script>

Session_Start is called when a user visits your site who hasn’t been there recently (usually in the last 20 minutes). Session_End is typically called when a session times out, which by default happens 20 minutes after the last request is received from the user for whom the session was created. The most common use for Session_Start is to initialize session state with data that is unique to each user. You’ll see examples later in this chapter.

Global.asax can also include handlers for events fired by HttpApplication instances. If present in Global.asax, the following methods are called in every request in response to HttpApplication events. They’re listed in the order in which they’re called.

These handlers let you customize ASP.NET by plugging into the request processing pipeline. For example, Application_ResolveRequestCache and Application_UpdateRequestCache could be used to implement a custom output cache. Application_AuthenticateRequest and Application_AuthorizeRequest provide hooks for modifying ASP.NET’s security apparatus. The event handlers Application_PreRequestHandlerExecute and Application_PostRequestHandler­Execute enable HTTP responses to be modified before they’re returned to clients. The following Global.asax file uses the latter of these two methods to place a copyright notice at the bottom of each and every page (assuming, of course, that your pages use HTML flow layout rather than absolute positioning):

<script language="C#" runat="server">
  void Application_PostRequestHandlerExecute (Object sender, EventArgs e)
  {
      HttpApplication app = (HttpApplication) sender;
      app.Context.Response.Write ("<hr><center><i>" +
          "Copyright © 2002 by Me, Myself, and I</i></center>");
  }
</script>

Outputting a copyright notice this way rather than duplicating it in every ASPX file lets you change it in one place to modify it everywhere it shows up.

The events listed above fire in each and every request. HttpApplication also defines an Error event that fires if ASP.NET throws an unhandled exception. You can process Error events by including an Application_Error handler in Global.asax. Here’s a Global.asax file that logs unhandled exceptions in the NT event log. It uses the FCL’s System.Diagnostics.EventLog class to write to the event log:

<%@ Import Namespace="System.Diagnostics" %> 

<script language="C#" runat="server"> 
  void Application_Error (Object sender, EventArgs e)
  {
      // Formulate a message to write to the event log
      string msg = "Error accessing " + Request.Path + "\n" +
          Server.GetLastError ().ToString ();

      // Write an entry to the event log
      EventLog log = new EventLog ();
      log.Source = "My ASP.NET Application";
      log.WriteEntry (msg, EventLogEntryType.Error);
  }
</script>

It’s not unwise to include a handler like this one in every ASP.NET application so that you can detect unhandled exceptions by periodically checking the NT event log. You could even modify the handler to send an e-mail message to a system administrator to apprise him or her of unhandled exceptions (a sure sign of a sick or buggy application) the moment they occur.

Don’t be surprised if you encounter a Global.asax file containing an event handler that’s not mentioned here. HttpApplication fires a few other events that I haven’t listed because they’re rarely used or used internally by ASP.NET. Plus, ASP.NET can be extended with HTTP modules that fire global events of their own. HTTP modules can also sink global events, which is precisely how the HTTP modules built into ASP.NET work much of their magic. A full discussion is beyond the scope of this chapter, but further information regarding HTTP modules and events is available in the Microsoft .NET Framework SDK.

Global object tags create object instances declaratively. Suppose you want a new instance of ShoppingCart created for each user that visits your site. Rather than do this:

<script>
  void Session_Start ()
  {
      Session["MyShoppingCart"] = new ShoppingCart ();
  }
</script>

you can do this:

<object id="MyShoppingCart" class="ShoppingCart" scope="session"
  runat="server" />

Assuming ShoppingCart has an Add method, a Web form could add an item to a user’s shopping cart by doing this:

MyShoppingCart.Add (...);

This code might not make a lot of sense right now, but it’ll make plenty of sense by the end of the chapter.

An <object> tag’s Scope attribute assigns a scope to the object instances it creates. Scope=“Application�creates one object instance, which is shared by all users of the application. Scope=“Session�creates one object instance per session (that is, per user). Scope=“Pipeline�creates a unique instance of the object for each and every request.

ASP.NET doesn’t create objects declared with <object> tags unless it has to—that is, until they’re requested for the first time. “Lazy instantiation�prevents objects from being created unnecessarily if the application doesn’t use them.