Scott Hanselman

Important Note: Replacing the default ViewState Persistance Behavior

June 03, 2004 Comment on this post [2] Posted in ASP.NET | ViewState | Bugs
Sponsored By

Scott Mitchell also has a good article on ViewState up on MSDN.

I talked to him before I blogged this and he agreed it was worth mentioning.  I blogged about this issue before

In his article Scott shows how one can override SavePageStateToPersistenceMedium and LoadPageStateFromPersistenceMedium to put ViewState somewhere else.  A few snippets are below:

   protected override void
     SavePageStateToPersistenceMedium(object viewState)
      LosFormatter los = new LosFormatter();
      StringWriter writer = new StringWriter();
      los.Serialize(writer, viewState);
      StreamWriter sw = File.CreateText(ViewStateFilePath);
   public string ViewStateFilePath
         string folderName =
         string fileName = Session.SessionID + "-" +
           "-") + ".vs";
         return Path.Combine(folderName, fileName);

In this example code (that you shouldn't copy/paste into production :) ) you see that he's redirecting ViewState to serialize to a file with a name like ASPNET23234094498230948320492834-myfile-default.aspx.vs. 

The problem (an edge case certainly, but still a problem) with this approach is that it doesn't support multiple browser windows on the same machine hitting the same page

Remember where ViewState is stored by default - it's stored with the requested page instance (in the HTML).  Using the ASP.NET SessionID in the filename scopes the state to the user and adding the file name reduces scope to the Page Declaration, but not the actual request instance.

Fortunately, Scott Mitchell wisely aludes to a solution in his article when he says:

Note   One workaround would be to use a globally unique identifier (GUID) as the file name for the persisted view state, saving this GUID in a hidden form field on the ASP.NET Web page. This approach, unfortunately, would take quite a bit more effort than using the SessionID / URL scheme, since it involves injecting a hidden form field into the Web Form. For that reason, I'll stick to illustrating the simpler approach for this article.

I spoke with Scott, and he agreed that for this solution to be more ideal one would have to implement a solution using a GUID.  Otherwise, be aware that you may run into flakey concurrence bugs where pages step on each other's ViewState.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
June 04, 2004 1:04
I actually did this using SQL Server in much the same way SQL Server session state is stored. This has worked fairly well except when the view state is really (>500kb) big, don't ask ;)
June 05, 2004 6:27
Note that Victor Garcia Aprea blogged about a very similar approach on May 11th.

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.