As in previous versions, each ASP application running on a machine has a single instance of the Application object, which can be accessed by any pages within that application. Any values or object references remain valid as long as the application is 'alive'. However, when the global.asax file is edited, or when the last client Session object is destroyed, the Application object is also destroyed.

Using the Application object for storing simple values is useful, and there are the usual Lock and Unlock methods available to prevent users from corrupting values within it through concurrent updates to these values. This can, however, cause blocking to occur while one page waits to access the Application object while it is locked by another page.

Note that when a page finishes executing or times out, or when an un-handled error occurs, the Application object is automatically unlocked for that page.

Bear in mind the impact of storing large volumes of data in an Application object, as this can absorb resources that are required elsewhere. You also need to ensure that any objects you instantiate at Application-level scope are thread safe and can handle multiple concurrent accesses. Another limitation in the use of the Application object is that it is not maintained across a Web farm where multiple servers handle user requests for the same application, or in a 'Web garden' where the same application runs in multiple processes within a single, multi-processor machine.