Scott Hanselman

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);
      <snip> 
   }
   public string ViewStateFilePath
   {
      get
      {
         string folderName =
           Path.Combine(Request.PhysicalApplicationPath,
           "PersistedViewState");
         string fileName = Session.SessionID + "-" +
           Path.GetFileNameWithoutExtension(Request.Path).Replace("/",
           "-") + ".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.

About   Newsletter

Hosting By