Inheriting from HttpApplication ASP

The code template for the code behind the global.asax has stubs of traps for a few events in
the request pipeline. Also present are Application_Start and Application_End, as well as
Session_Start and Session_End. These are holdovers from classic ASP. The application start
event is fired when the first instance of HttpApplication is created within an application
domain. Requests are processed within an IIS application from a pool of HttpApplication
objects.
Session start and end are fired as sessions are created and torn down. You can do your
own user-specific allocation and disposal of resources in traps of these events.
The events of the HttpApplication pipeline can be trapped by using a method naming
convention:
Public void Application_OnEventName(Object sender, EventArgs e)
The ASP.NET runtime gives global.asax special treatment. Even though there’s no code
creating the delegate and passing it to this event definition, code is generated behind the
scenes that sinks the event. This is a very VB-like strategy, telling the developer to “pay no
attention to the code generator behind the curtain.”
You also cannot override the default constructor and provide your own code to sink these
events, as the code generation that occurs at runtime also generates a default constructor for
the same class, resulting in a compile error when you provide your own default constructor.
There’s also no way to reference any public field defined at the class level with the inline
script model. Adding a public static field to this class definition is the recommended alterna-
tive to using the Application object. Accessing a static field is much quicker than doing a
lookup from the Application state bag. If any modifications are made to these fields, access
must be synchronized, of course. But this is the case with the Application object as well (it
provides the Lockand Unlockmethods to do this), and it’s best to use these fields for read-only
information you want to make available to your entire application.
However, with the inline script model, the class doesn’t exist until the code generation
step at runtime, and unlike most of the dynamically created classes in the ASP.NET 2.0 envi-
ronment, you cannot reference it within the integrated development environment (IDE) at
design time. This is true even when you add the ClassName attribute to the Application
directive.
For these reasons, as well as the other many benefits of the code-behind model, there are
benefits you can gain from using the ASP.NET 1.x model for the global.asax, instead of relying
on the template in ASP.NET 2.0.
When a global.asax is added to a Web project, the default template uses on inline script
block:

<%@ Application Language="C#" %>

<%@ Application Language="C#" %>