Application Class and Application Instances
An application class is defined in the Global.asax file. The code
in Global.asax defines a new class that is derived from System.Web.HttpApplication
. In the absence of a Global.asax file, the base class, HttpApplication
, is used as the application class.
The ASP.NET runtime
creates as many instances of application classes as needed to process requests
simultaneously. For most applications, this number is limited to the number of
threads and remains in the range of 1 through 100, depending on the hardware,
server load, configuration, and so on. Many requests reuse application
instances, and a free list of application instances is kept during periods of
reduced load. Application instances are used in a thread-safe manner, that is,
one request at a time. This has important implications:
- You do not have to worry about locking when you access
non-static members of the application class.
- Application code can store request data for each request in
non-static members of the application class (but not after the EndRequest event because this event may maintain the request for a long
Because static members of any class, including an application
class, are not thread-safe, the user code must provide appropriate locking for
access to static members. This applies to any static member that you add to the
Use the following guidelines to access the
application instance that is associated with the current request:
- From the Global.asax, use the this or Me object.
- From a page, every page includes a strongly-typed ApplicationInstance property.
- From the HttpContext object, use the HttpContext.ApplicationInstance property (which you type as HttpApplication).
refers to the global application state dictionary in classic ASP,
ASP.NET uses ApplicationInstance
and not Application
as a property name to refer to the application instance that
processes the current request.
The lifetime of a request consists of a series of the application
events (and some implicit steps that ASP.NET implements). These events are
listed below in the order in which they are executed:
- AuthenticateRequest event
- DefaultAuthentication internal event
- AuthorizeRequest event
- ResolveRequestCache event
- Internal step to "map handler" (when compilation takes
place, a page instance is created)
- AcquireRequestState event
- PreRequestHandlerExecute event
- Internal step to "execute handler" (when the page code is
- PostRequestHandlerExecute event
- ReleaseRequestState event
- Internal step to filter responses UpdateRequestCache event
- UpdateRequestCache event
- EndRequest event
If you use Server.Transfer
, the current request is effectively interrupted and some of the events that are listed above will not be raised. However, the EndRequest
event will be raised in this scenario.
The following items can handle these events:
- Internal ASP.NET page framework (for example, steps 6, 9,
and 12 in the preceding list).
- HTTP modules that are configured for the application. The
default list of HTTP modules is defined in the Machine.config file.
- Code in Global.asax that is hooked through the Application_[On]EventName method or that is hooked explicitly when you add event handlers
for an alternative handler name.
Each event can have synchronous and asynchronous subscribers.
Asynchronous subscribers are executed first. Not all events are always
executed; the only event that is always executed is EndRequest
. As a result, perform all after-request cleanup in the EndRequest
In most cases, the actual response is sent to the client after
the application instance is finished with the response (which is after EndRequest
Application_OnStart and Application_OnEnd
ASP.NET introduces the unique Application_OnStart
"events" for compatibility with classic ASP. These "events" are
executed only once in the lifetime of an application and not for every
application instance. Therefore, if you change non-static members in these
methods, you affect only one application instance and not all instances. You
can initialize one application instance either in the constructor or by
overriding the Init
is a logical equivalent to the class constructor for the
application class, but it offers one advantage: the code has access to the HttpContext
for the first request to the application.
Application state is a global dictionary of late-bound objects,
which classic ASP introduces to compensate for the absence of global variables
in Microsoft Visual Basic Scripting Edition (VBScript). In ASP.NET, you can
access application state through one of the following:
- Application property (which is defined in both HttpApplication and Page classes)
ASP.NET includes application state primarily for compatibility
with classic ASP so that it is easier to migrate existing applications to
ASP.NET. It is recommended that you store data in static members of the
application class instead of in the Application
object. This increases performance because you can access a
static variable faster than you can access an item in the Application
To access static application members from pages in
Microsoft Visual C# .NET and Microsoft Visual Basic .NET, you must use the ClassName
attribute in Global.asax to name your application class. For
<%@ Application Language="C# | VB" ClassName="MyClass" %>
If a static member is named MyStaticMember
in your Global.asax file, you can use MyClass.MyStaticMember
to access it from your page.
Article ID: 312607 - Last Review: June 19, 2014 - Revision: 6.0
- Microsoft ASP.NET 1.1
- Microsoft ASP.NET 1.0
|kbappdev kbhttpruntime kbinfo kbstate KB312607|