Microsoft Dynamics CRM 4.0 doesn’t use ViewState, or Sessions. Indeed, they are disabled in the web.config file. This can be a bit of a surprise to an ASP.NET developer working on a custom page in the /ISV directory.
Three possible solutions on ViewState:
1) Don’t use ViewState.
2) You can enable viewstate for a particular page by adding it to the page directive at the top of the page:
<%@ Page . . . EnableViewState="true" . . .
Note that if you have a server cluster and use viewstate, you’ll either need to set a machine key in web.config or else disable viewstate validation with another Page directive:
<%@ Page . . . EnableViewState="true" EnableViewStateMac="false" %>
Disabling ViewStateMac means your users will be able to tamper with the viewstate, so just keep that concern in mind if you have custom permissioning rules in your app beyond CRM’s built in permissioning.
3) You can enable viewstate for all of your ISV pages by setting it up as its own app.
Create a virtual directory under /ISV, point it to your pages, and give yourself a web.config that sets enableviewstate for your pages (and a machine key). See, for example, this guide at xrmlinq.
Remember that if you’re going to use viewstate, you should keep an eye on viewstate size ; perhaps you don’t want to transfer a megabyte of serialized grid data with every page load. You can see how big viewstate is by viewing source on your page, or by adding some code to your pages (If Request.IsLocal is true and DEBUG is defined, I tack on a label with the size from LosFormatter; see example code at scottonwriting ); but in general, if you use viewstate on a grid or listbox, you’re going to be storing a lot of data. If you’d rather repopulate your grid or listbox with every request instead of serializing their data, simply databind them before viewstate begins being tracked - during init instead of during load. See ASP.NET Page Lifecycle.
As for Sessions, I would recommend avoiding them. You’ll probably have some real headaches if you need to support the offline client and rely on sessions, and it can be hard to anticipate (and test for) how sessions will be affected by one user popping several windows open. In general, if data is ephemeral it can be handled well by viewstate. If data is not ephemeral, you probably want to be storing it in a database. So pass on session.