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)