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( ); }
System.Collections.Specialized.NameObjectCollectionBase(System.Collections.ICollection, System.Collections.IEnumerable, System.Runtime.Serialization.ISerializable, System.Runtime.Serialization.IDeserializationCallback) 