Home   |   QuickStart Welcome   |   ASP.NET   |   Web Services   |   How Do I...?   
  |   I want my samples in...      

ASP.NET 2.0 Quickstart Tutorials

Understanding Applications and State

What's New in 2.0

  • Session State Extensibility - Session State is now built upon a fully extensible, provider-based storage model. ASP.NET 2.0 ships with providers for in-process, out-of-process and Sql Server storage. However developers can implement custom providers that work against other data stores by deriving from SessionStateStoreProviderBase. The Session State feature also allows developers to create custom session ID generators as well as custom HttpModules to use instead of the default SessionStateModule. For scalability, the Sql Server and out-of-process Session State providers allow a developer to dynamically determine on a per-request basis the session state server that should load and store session data. This allows session state data to be spread across multiple backend session state servers.

  • Control State - In addition to ViewState, controls can now use a ControlState dictionary for round-tripping state information using the client. The ControlState dictionary is intended to store limited size information that is critical to the functionality of the control, that should not be disabled when EnableViewState is false.

  • Encrypted ViewState - ASP.NET 2.0 enables encryption of ViewState through the Page directive's EncryptViewState attribute. This can be used to protect sensitive data that needs to be roundtripped in viewstate that should not be exposed to the client user. A common use for this feature might be to encrypt the DataKeyNames values from a GridView control.
This section discusses these and other application and state management features in ASP.NET 2.0.

What is an ASP.NET Application?

ASP.NET defines an application as the sum of all files, pages, handlers, modules, and executable code that can be invoked or run in the scope of a given virtual directory (and its subdirectories) on a Web application server. For example, an "order" application might be published in the "/order" virtual directory on a Web server computer. For IIS the virtual directory can be set up in the Internet Services Manager; it contains all subdirectories, unless the subdirectories are virtual directories themselves.

Each ASP.NET Framework application on a Web server is executed within a unique .NET Framework application domain, which guarantees class isolation (no versioning or naming conflicts), security sandboxing (preventing access to certain machine or network resources), and static variable isolation.

ASP.NET maintains a pool of HttpApplication instances over the course of a Web application's lifetime. ASP.NET automatically assigns one of these instances to process each incoming HTTP request that is received by the application. The particular HttpApplication instance assigned is responsible for managing the entire lifetime of the request and is reused only after the request has been completed. This means that user code within the HttpApplication does not need to be reentrant.

Creating an Application

To create an ASP.NET Framework application you can use an existing virtual directory or create a new one. For example, if you installed Windows 2000 Server including IIS, you probably have a directory C:\InetPub\WWWRoot. You can configure IIS using the Internet Services Manager, available under Start -> Programs -> Administrative Tools. Right-click on an existing directory and choose either New (to create a new virtual directory) or Properties (to promote an existing regular directory).

By placing a simple .aspx page like the following in the virtual directory and accessing it with the browser, you trigger the creation of the ASP.NET application.

<%@Page Language="C#"%>
<h1>hello world, <% Response.Write(DateTime.Now.ToString()); %></h1>

Now you can add appropriate code to use the Application object--to store objects with application scope, for example. By creating a global.asax file you also can define various event handlers-- for the Application_Start event, for example.

Lifetime of an Application

An ASP.NET Framework application is created the first time a request is made to the server; before that, no ASP.NET code executes. When the first request is made, a pool of HttpApplication instances is created and the Application_Start event is raised. The HttpApplication instances process this and subsequent requests, until the last instance exits and the Application_End event is raised.

Note that the Init and Dispose methods of HttpApplication are called per instance and thus can be called several times between Application_Start and Application_End. Only these events are shared among all instances of HttpApplication in one ASP.NET application.

A Note on Multiple Threads

If you use objects with application scope, you should be aware that ASP.NET processes requests concurrently and that the Application object can be accessed by multiple threads. Therefore the following code is dangerous and might not produce the expected result, if the page is repeatedly requested by different clients at the same time.

Application["counter"] = (Int32)Application["counter"] + 1;

To make this code thread safe, serialize the access to the Application object using the Lock and UnLock methods. However, doing so also means accepting a considerable performance hit:

Application["counter"] = (Int32)Application["counter"] + 1;

Another solution is to make the object stored with an application scope thread safe. For example, note that the collection classes in the System.Collections namespace are not thread safe for performance reasons.