ASP.NET.in.a.Nutshell.Second.Edition [Electronic resources]

This class provides server-side state management that is available globally across all client sessions in an ASP.NET application. Application state is not shared across multiple ASP.NET applications, or across multiple processes or multiple computers in a single application. (In other words, proxy load balancing in a web farm can thwart this type of state management.) If you need to store state across multiple web servers, you may want to use session state instead (see the System.Web.SessionState.HttpSessionState class for more information).

The HttpApplicationState class exposes a name/value collection of items that can store simple value types or instances of .NET objects. A single instance of the class is created automatically the first time a client requests a page in the ASP.NET virtual directory. A reference is provided through the built-in Application object.

The HttpApplicationState class combines two state collections: Contents and StaticObjects. The StaticObjects collection contains the application state objects that are defined in the global.asax file with <object runat=server> tags. This collection is immutable. The Contents collection contains all the state objects added at runtime.

The Item collection is the default indexer for HttpApplicationState, so you can use the name of a state object as an index, as in: Application("globalcounter") = 1;. If you assign a value to a state object that does not exist, it is created automatically. Items are stored as the generic System.Object type and must be cast to the appropriate types when you retrieve them.

Multiple clients or threads can access application state values simultaneously. To avoid synchronization problems, use the Lock( ) method to gain exclusive access to the application state collection before adding or retrieving an item, followed by the UnLock( ) method. This approach can result in performance degradation, which makes this type of state management unsuitable for frequently modified values. Using another form of state management or a relational database is usually a better alternative. HttpApplicationState objects should also be thread-safe, or you should use synchronization techniques (like the SyncLock statement).

public sealed class 
HttpApplicationState  : System.Collections.Specialized.NameObjectCollectionBase {
// Public Instance Properties
public string[ ] 
AllKeys {get; }
public HttpApplicationState 
Contents {get; }
public override int 
Count {get; }  // overrides System.Collections.Specialized.NameObjectCollectionBase
public HttpStaticObjectsCollection 
StaticObjects {get; }
public object 
this [string 
name ]{set; get; }
public object 
this [int 
index ]{get; }
// Public Instance Methods
public void 
Add (string 
name , object 
value );
public void 
Clear ( );
public object 
Get (int 
index );
public object 
Get (string 
name );
public string 
GetKey (int 
index );
public void 
Lock ( );
public void 
Remove (string 
name );
public void 
RemoveAll ( );
public void 
RemoveAt (int 
index );
public void 
Set (string 
name , object 
value );
public void 
UnLock ( );
}

Hierarchy

System.Object System.Collections.Specialized.NameObjectCollectionBase(System.Collections.ICollection, System.Collections.IEnumerable, System.Runtime.Serialization.ISerializable, System.Runtime.Serialization.IDeserializationCallback) HttpApplicationState

Returned By

HttpApplication.Application, HttpContext.Application, System.Web.Services.WebService.Application, System.Web.UI.Page.Application, System.Web.UI.UserControl.Application