Hopefully, you reached this page from the About Visual Basic ASP.NET Hub Page. If not, you might want to click the link above and go there.
The entire web is inherently "stateless" because it's a fundamental part of the http protocol which controls the way the entire web works. Click here for an overview of state in ASP.NET including links to articles describing other ways to maintain state. This article tells you what application state is and how to use it.
Microsoft defines an ASP.NET application as, "all the files, pages, handlers, modules, and executable code that can be invoked from a virtual directory and its subdirectories on a Web application server." If you persist information in application state, you can retrieve it again from anywhere in the entire application.
Application state is the fastest and broadest way to preserve state. But it does have drawbacks. In common with the default mode of session state, the information is stored in server memory so you have to be careful about overloading the server. Unlike session state, you don't have any choice about where information is saved with application state; it's always in server memory. That means that if the server crashes for any reason, application state information is lost. Another problem is that it doesn't scale well because application state can't be shared across multiple servers or processes. And finally, you have to be careful with multithreaded applications. You can run into data integrity problems.
Speed is one reason why some developers like application state. But another is that application state information is a lot like global variables for an entire ASP.NET application. But those variables aren't automatically available ... you have to load them. In general, you can load application state variables using code in global.asax or in Page.Load.
You can also work with all of the application state variables as a collection. This code, for example, puts all of them in a ListBox so you can see what they are:
Dim i As Integer = 0 Dim j As Integer = Application.Count Dim appVar As Object Dim appVarName As String Do While i < j appVar = Application.Contents.Item(i) appVarName = Application.Contents.GetKey(i) ListBox1.Items.Add(appVarName & ": " & appVar.ToString) i += 1 Loop
But until the server is restarted, application state information will be available to any program in the application, even if the application is closed and reopened. But each application still gets it's own unique instance of application state. A separate single instance is created for each ASP.NET application on the server.
The advantages of application state make it a natural for small amounts of data that have to be shared across multiple sessions and users. But since it's free threaded, you can run into invalid data problems with multiple users. To solve this problem, ASP.NET gives you an Application.Lock() and Application.UnLock() method so your code can update variables.
Application.Lock() Application("VoteCount") += 1 Application.UnLock()
As an interesting side note, the above code doesn't work at all with Option Strict since application state variables are all of type Object and have to be converted to Integer and back to Object. You can usually count on VB to do the conversions without any problems, but occasionally, it can create an issue. For example, if the application state variable NoSuchVar doesn't exist and you code ...
Dim theType As Type = Application("NoSuchVar").GetType
... you get a NullReferenceException because you can't examine the type of a Null.