This post originated from an RSS feed registered with .NET Buzz by Scott Hanselman. Original Post: Important Note: Replacing the default ViewState Persistance Behavior Feed Title: Scott Hanselman's ComputerZen.com Feed URL: http://radio-weblogs.com/0106747/rss.xml Feed Description: Scott Hanselman's ComputerZen.com is a .NET/WebServices/XML Weblog. I offer details of obscurities (internals of ASP.NET, WebServices, XML, etc) and best practices from real world scenarios. Latest .NET Buzz Posts Latest .NET Buzz Posts by Scott Hanselman Latest Posts From Scott Hanselman's ComputerZen.com

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.