View State works by taking advantage of a hidden form field that is automatically added to every Web Form Page. You can see this hidden form field if you select View Source when displaying a Web Form Page in a browser. For example, the View State hidden form field looks like the following when I click View Source for the ShowViewState.aspx page:

<input type="hidden" name="__VIEWSTATE"
value="dDwxNTg0NTEzNzMyO3Q8O2w8aTwxPjs+O2w8dDw7bDxpPDE+Oz47bDx0PHA
8cDxsPFRleHQ7PjtsPExhYmVsXDxsaVw+aGVsbG9cPGxpXD5taWxrOz4+Oz47Oz47P
j47Pj47PgIWH/qU4XKz/lwgBle3On0unW/h" />

Immediately before a page is rendered, the values of the properties of all controls in a page are converted into a string. When the page is rendered, this string is assigned to the hidden__VIEWSTATE form field. When the page is posted back to the server, the string is parsed and all the values are reassigned to the properties of the controls in the page.

View State can be both a blessing and a curse. View State enables you to magically retain the state of all the controls on a page. However, the hidden VIEWSTATE form field can become very large, which can slow down the rendering of a page.

You don’t always need to take advantage of View State. If you don’t need to preserve the state of controls across post backs, you don’t need to use View State.

For example, suppose that you have a Web Form Page that displays all the products in the Products database table in a DataGrid. The information about all the products is automatically stuffed into View State. If you are simply viewing the data in the DataGrid, you don’t really need to do this. You only need to preserve the state of a DataGrid when performing such operations as sorting, editing, or paging a DataGrid. If you are only viewing the data, the View State consumed by the DataGrid is a waste of bandwidth.

You can disable View State for any control by assigning the value False to its EnableViewState property. You should always disable View State for controls such as the Repeater, DataList, and DataGrid controls when you are simply displaying data.

You also can disable View State for all the controls in a page by using the DOCUMENT EnableViewState property. To disable View State for a page, select DOCUMENT in the Properties window and assign the value False to the EnableViewState property.

Finally, you can disable View State for an entire application (or particular directory or file in an application) within the Web.Config file. Add the following tag to the System.Web section of the Web.Config file:

<pages enableViewState="false" />

You can display the amount of View State that each control in a page is consuming by enabling tracing for a page. In the Properties window, select DOCUMENT and assign the value True to the Trace property. If you build and browse the page, you’ll see the amount of View State associated with each control in the Control Tree section appended at the bottom of the page (see Figure 17.2).

Figure 17.2. Viewing View State statistics.

You can add your own data to View State by taking advantage of the ViewState collection. Any data that you add to the ViewState collection will be stuffed into the __VIEWSTATE hidden form field and will be preserved across postbacks.

For example, the following statement adds the string “Hello World” to the ViewState collection:

C#. 

ViewState[ "myItem" ] = "Hello World";

VB.NET. 

ViewState("myItem") = "Hello World"

After an item has been added to the ViewState collection, you can retrieve the item by passing the name of the item to the collection:

C#. 

Response.Write( ViewState[ "myItem" ] );

VB.NET. 

Response.Write(ViewState("myItem"))

You can add almost any object to the ViewState collection, including strings, integers, ArrayLists, Hashtables, and even DataSets. The only requirement is that the object must be serializable.

However, remember that anything you add to View State must be stuffed into the __VIEWSTATE hidden form field. Consequently, adding a DataSet to View State can significantly impact the rendering time for a page. In general, you should stick to objects that have optimized View State serializers—strings, integers, Booleans, arrays, ArrayLists, and Hashtables.

By default, View State is not encrypted. In theory, anyone requesting a page can copy the page to their local hard drive, modify the value of the hidden __VIEWSTATE form field, and submit the modified page back to the server.

For example, if you are storing a shopping cart in View State, someone could modify the price of all the products in the shopping cart and submit the modified page. A great way for users to give themselves massive discounts!

You can protect the integrity of View State by adding a Message Authentication Code (MAC) to the hidden __VIEWSTATE form field. After the View State MAC is enabled, an exception is thrown if someone tampers with the View State.

You can enable the View State MAC for a particular Web Form Page by selecting DOCUMENT in the Properties window and assigning the value True to the EnableViewStateMAC property. You can enable the View State MAC for an application or directory by adding the following tag to the System.Web section of the Web.Config file:

<pages enableViewStateMac="true" />

The View State MAC is disabled by default. Enabling the View State MAC adds some extra work to the processing of the page, so it has an impact on performance. If you don’t need it, don’t enable it.

Enabling the View State MAC does not result in the View State being encrypted. If you want to encrypt the contents of View State, you need to enable the View State MAC and perform an additional step. You need to add the following tag to the System.Web section of the Web.Config file:

<machineKey validation="3DES" />

This tag causes all View State to be encrypted using the Triple Data Encryption Standard. Again, this has an impact on performance, so don’t enable it unless you need it.

By default, Session State is stored in the same process as the Web server. In other words, when you add an item to Session State, it’s added to the same memory being used by the Web server process. This has several bad consequences.

If the Web server process is stopped or becomes corrupted, all Session State information is lost. For example, if you are storing shopping carts in Session State and your Web server crashes, all the shopping carts will disappear.

Furthermore, because in-process Session State is stored on a particular Web server, you can’t load balance requests across multiple servers. In other words, if you use inprocess Session State, you can’t create a Web farm. This restriction limits the scalability of your Web application.

ASP.NET supports two out-of-process forms of Session State that get around these two problems. You can store Session State in either an external Windows Service or an external database table. Enabling out-of-process Session State makes Session State more reliable and more scalable.

<sessionState
  mode="StateServer"
  stateConnectionString="tcpip=127.0.0.1:42424"
  stateNetworkTimeout="10" />

iisreset

<sessionState
  mode="SQLServer"
  sqlConnectionString="data source=127.0.0.1;user id=sa;password=secret" />

SELECT * FROM tempDB..AspStateTempSessions

By default, Session State relies on browser cookies. When you first request a Web Form Page from an ASP.NET Web Application, the server automatically adds a cookie to your browser called the ASP.NET_SessionID cookie. The server uses that cookie to identify you when you request a new page.

Session State depends on this cookie to associate the right Session State information with the right user. If cookies are disabled on a browser, Session State will fail. The Web server will assume that you are a new user each and every time that you request a new page.

When you are creating a public Web application, it’s dangerous to rely on cookies. For a variety of reasons, cookies don’t always work. This means that Session State will not always work.

Fortunately, there is a way around this problem. Session State supports something called Cookieless Sessions. As the name implies, you can use Cookieless Sessions to maintain Session State without relying on browser cookies.

You can enable Cookieless Sessions by modifying a single attribute in the Web.Config file. Find the <sessionState> tag in the application root Web.Config file and modify it as follows:

<sessionState
  cookieless="true" />

Cookieless Sessions are compatible with both in-process and out-of-process Session State, so you can use Cookieless Sessions regardless of whether you are storing state information in process or in a database table.

You can test Cookieless Sessions by opening the Session1.aspx page that we created at the beginning of this section. When the page opens, you should notice that the contents of the address bar look a little strange. The address bar should look something like the following:

http://localhost/myApp/(rtobxqzq5cjkswbtmpgj0×45)/Session1.aspx

The string of characters between the parentheses is the current Session ID. When you click the link in the Session1.aspx page, this Session ID is passed to the Session2.aspx page in the URL. The Web server can identify you without using cookies as you move from page to page by extracting this Session ID.

You should be aware that Cookieless Sessions do not work in exactly the same way as normal Session State. Normally, when you open multiple instances of a browser when visiting a Web site, all browser instances share the same Session State. On the other hand, if you open multiple browser instances when using Cookieless Sessions, the Session State information will not be shared.

Cookieless Sessions also force you to design your pages in a particular way. If you want to take advantage of Cookieless Sessions, you need to make all the links in your pages use relative URLs. If you add an absolute URL, the Session ID information will be lost.