ASP.Net View State - Little Known Facts

1. View State is not encrypted but patched together in memory and converted to a Base64 string. A hash code is added to the end by default and hence protects from changes on the client side. Since the keys used by ASP.NET are not known hence it is secure.

2. View State will not work in cases of a server farm where the machine that intercepts the subsequent request can be different and hence have a different key for hashing. This can be overridden by using same key on all the servers.

3. The hash code is enabled by default. To disable it:
<configuration xmlns="<a href=">http://schemas.microsoft.com/.NetConfiguration/v2.o</a>">

<system.web>

<pages enableviewstatemac="false">

</system.web>

</configuration>

4. The view state can be encrypted on a page basis by using:<%@Page ViewStateEncryptionMode="Always" /> OR can be set in the web.config using The options are Always, Never and Auto. In case of auto the individual controls must call Page.RegisterRequiresViewStateEncryption();

5. Don't encrypt the view state unless you need to because of performance reasons.
6. All objects that needs to be stored must be serializable.


One of the limitations of View State is that it gets lost when the user navigates to a new page. The are two solutions to it:

1. Cross-Page Posting:
The infrastructure that supports cross page posting is PostBackUrl provided by IButtonControl and turns up in button controls like ImageButton, LinkButton and Button. To cross post simply set the PostBackUrl to the new form and when the button is clicked all the values form the user controls on the current page is transferred to the new page.

On the next page you can use the Page.PreviousPage to check the page you came from. In case of a direct access / post back previous page is null.
On the next page you can cast the PreviousPage to the appropriate page and use the values of all the controls.

This problem can also be solved by specifying the previous page type to the .aspx page, right after the page directive. e.g:
<%@ PreviousPageType VirtualPath="CrossPage1.aspx" %> This limits you to a single page class.

Another issue is accessing the values on the new page. Since the controls are protected by default, you should create properties that extract the info from the controls and can be used to access.

The first time the second page accesses Page.PreviousPage, ASP.NET needs to create the previous page object. To do this, it actually starts the page processing but interrupts it just before the PreRender stage, and it doesn't let the page render any HTML output.

This has some side effects, all the page events are fires, including Page.Load and Page.Init and the Button.Click event also fires for the button that triggered the cross-page post back. ASP.NET fires these events because they might be needed to initialize the source page.

2. Query String:
?a=value&b=value
Clear Text, Size Limited to 1 - 2 KB based on browser.

3. Custom Cookies:
Limited to simple strings.
Easily accessible and readable.
Users can disable cookies.