Server Side Viewstate
page 1 of 1
Published: 10 Oct 2003
Unedited - Community Contributed
Abstract
Store viewstate information on the web server to avoid corrupted viewstate and browser limitations.
by Robert Boedigheimer
Feedback
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 91980/ 51

Background

ViewState is a feature provided by ASP.Net that stores information for server controls used on a web page. The primary advantage of this feature from a developer perspective is that it keeps the values of controls on a form. If the user forgot a single required field on a form, ASP.Net can put back the other values they had entered rather than forcing the developer to repopulate them. The information is encoded into a string and placed in a hidden form field called “__VIEWSTATE” that is sent to the client with the response (you can see this by using View Source in your browser when you view a .aspx page). ASP.Net by default also calculates a “hash” of the information and adds it to the ViewState, then on a postback it can validate that the data has not been corrupted. That is a basic description of what viewstate is and how it is implemented, this article will focus on where the viewstate information is stored.

The Problem

After converting our web site from ASP to ASP.Net, we began to have problems with viewstate exceptions. We would receive "The View State is invalid for this page and might be corrupted" about 50 times a day. We searched for known causes for this problem and none of them applied to our situation. After several network traces and calls to Microsoft Support, we determined that when network retransmissions occurred the client would sometimes have a corrupt version of the HTML page (we were never able to determine why TCP did not detect the corruption). If the corruption happened to occur inside the viewstate hidden field value, it would cause the exceptions (the recomputed hash on the server did not match the original hash). We also determined that several browsers (such as older WebTV clients) could not handle large hidden form fields. Our solution was to save the viewstate for the pages on the web server using the Session object instead of the HTML result sent to the client.

Benefits of Server Side ViewState

  • Avoid corruption problems
  • Avoid issues with browsers that limit the maximum size of hidden fields
  • Reduced client page size - since the viewstate information is stored on the server it is not sent in the response to the client which saves download time and bandwidth

Disadvantages of Server Side ViewState

  • Uses server side memory for the in-process session object
  • Not as obvious to developers how much space is used by viewstate

The Solution

The idea is to override the default handling of viewstate provided by ASP.Net and implement a custom implementation to store the viewstate information on the server. Originally I was not enthusiastic about the idea of rewriting some of the basic functionality provided by ASP.Net, but it was very easy to do and eliminated our problems.

Since the viewstate is specific to each user, we decided to store the information using the Session object. Our servers use in-process session state (stored in web server memory), so we wanted to limit the amount of viewstate we had to store for each user. We cannot simply store the last viewstate for user, however, because a user can visit a page in Internet Explorer, hit the back button to a previous page and push a button (which would require the viewstate for that page). This requires us to support multiple versions of viewstate for each user. The number of page viewstate values to store is a tradeoff between memory and support for pressing the back button a number of times. The example solution stores the last 5 viewstate values for each user. The viewstate values are stored in a circular array using the modulus operator (% in C#). Every time a user requests a new page on the site, the code increments a request number and uses that number as a key to the proper viewstate in the array on the server. The code uses the modulus of the request number and the size of the array to determine the index into the circular array. This starts storing viewstate for the first page (request number 1) in index 1 of the array (1 % 5 = 1), request 2 would use index 2, etc. This continues until the request number hits 5, which wraps back around and uses index position 0. This is a simple way to use a fixed size array efficiently. The code stores the request number in the “__VIEWSTATE” field that was previously used to store the actual viewstate information. The code consults the web.config file to determine if it should use server side or client side viewstate (changes to the web.config will drop the in-process Session object for the user which will drop all current viewstate, make changes to this during off peak times).

Instructions for Using

The first step in implementing the solution is to download the two C# files that implement the server side functionality and add them to your ASP.Net project.

BasePage.cs

This file includes the class BasePage which is used as a parent class for all pages on the site and can be used without modification. The use of a custom base class has many advantages for an ASP.Net site, in this case it is used to override the default viewstate handling provided by System.Web.UI.Page. The two methods that this class overrides are LoadPageStateFromPersistenceMedium() which is called to reload the viewstate on a postback, and SavePageStateToPersistenceMedium() which is called to save the viewstate before sending the results to the client. The override of these methods simply check if server side viewstate is enabled, then call methods to do the work if it is (otherwise they just invoke the original Page class methods). The LoadViewState() method checks for the __VIEWSTATE field and attempts to convert it to a long (which would fail if the viewstate was actually the original encoded string). If it successfully retrieves the value, it uses another class viewStateSvrMgr to retrieve the viewstate from the session. The SaveViewState() method uses the viewStateSvrMgr class to save the viewstate to the session, and writes the hidden form field __VIEWSTATE to the client page with the request number key. If you are using the .Net 1.1 framework, you should change the name used for the hidden field value, which is stored in the constant VIEW_STATE_FIELD_NAME in this file (anything other than __VIEWSTATE).

All web pages for the site must derive from the BasePage class. The default file webForm1.aspx.cs in an ASP.Net project has the original class declaration “public class WebForm1 : System.Web.UI.Page”, this is changed instead to “public class WebForm1 : ServerSideViewstate.BasePage”.

viewStateSvrMgr.cs

This provides the majority of the code required for server side viewstate. A constant at the top of the file VIEW_STATE_NUM_PAGES controls the number of viewstate values kept for each user. This can be adjusted as necessary to conserve memory, but if the user hit the back button more times than this array size and did a postback, the viewstate data would not be present which will affect page behavior for controls and events. This file also uses a technique that stores an object in session rather than storing multiple independent session variables. The GetViewStateSvrMgr() method checks if an object of this class has already been created and stored in session or if it needs to do so. Then the class can simply store local variables that are all stored in that single session object, which helps avoid pollution of the Session with lots of independent keys with no relation between them. Pages that need to use the services of the class call GetViewStateSvrMgr() and get an instance of the class they can use to get/save viewstate information. The property ServerSideEnabled abstracts the check for whether the server side viewstate is enabled or not (via the web.config setting). The methods SaveViewState() and GetViewState() manage the circular array which is a member of the class, and hence is stored in the object that is placed in the session object for this user.

The last step is to add the following to the web.config file (place just above the </configuration> entry:

<appSettings>
<add key="ServerSideViewState" value="true" />
</appSettings>

Testing

Once the files have been added to the project, the pages have been changed to derive from the BasePage class, and the changes to web.config have been made the site will start to use the session to store viewstate. This can be validated by visiting one of the .aspx pages on the site and using the View Source option of the browser, search for the __VIEWSTATE and notice that it is no longer a large encoded string, but a request number that is the key to the location of the viewstate for the page on the server.

Conclusion

This solution still supports the EnableViewState property for pages and controls and the viewstate size can be seen with tracing, this technique simply changes where the viewstate will be stored. The original driver of using Server Side ViewState was some corruption problems and lack of browser support for large hidden form fields. The use of the described technique solves both of those problems, while also reducing the page size sent to the client.

Send comments or questions to robertb@aspalliance.com.


User Comments

Title: ere   
Name: er
Date: 2012-09-18 3:26:14 AM
Comment:
ere
Title: Re: Flavio   
Name: Robert Boedigheimer
Date: 2012-08-10 4:30:50 PM
Comment:
What is commonly in viewstate is the state information needed by built in controls. I rarely store anything of my own in viewstate. Since most ASP.NET controls do use viewstate for eventing, state, etc you typically have a large viewstate. If you can disable viewstate on the controls and everything works I would do so.
Title: Question   
Name: Flavio
Date: 2012-08-10 4:15:01 PM
Comment:
Hi, what do you want to store in viewstate? why not use Session variable?
Title: Re: Chowdary   
Name: Robert Boedigheimer
Date: 2011-06-24 9:16:53 AM
Comment:
Are you having the issue only when you use the server side technique or all of the time? I use custom veiwstate with this and it works fine for me.
Title: custome view state   
Name: chowdary
Date: 2011-05-04 12:53:43 AM
Comment:
this article is useful in saving the view states of controls in server side, but i am facing problem with custom viewstate, these values are not persisting, these values are clearing just after creation.
Title: VB.NET version for mobile pages - Link   
Name: Yalin Meric
Date: 2010-10-22 8:47:52 AM
Comment:
I didn't know that the url field in feedback was not meant to provide links to readers. Here is the link:
http://www.yalinmeric.info/download/MobilVB2005.zip
Title: VB.NET version for mobile pages   
Name: Yalin Meric
Date: 2010-10-22 8:46:17 AM
Comment:
Hello all. First I want to thank Robert for his kind solution that helped me overcome my viewstate problem with mobile pages I developed. I converted the supplied C# classes to VB versions and uploaded them to my web site for whom it may concern. Please use the link I provided above.
Title: problem   
Name: dharmaraju
Date: 2010-10-20 4:07:13 AM
Comment:
its verry good solution for the developer who have the problem in this
Title: Facing Problem   
Name: Izabela
Date: 2010-06-22 5:19:51 AM
Comment:
Very interesting article indeed. But what is more interesting is that, I was receiving "The state information is invalid for this page and might be corrupted. " error while browsing my file in internet explorer but after applying the steps in you article I am receiving the error in mozilla too. Do you have any suggestion for my situation. Thank you in advance.
Title: sdfas   
Name: asd
Date: 2010-05-10 5:32:10 AM
Comment:
Funny thought
Title: gotit!   
Name: Franz
Date: 2009-05-11 7:03:56 AM
Comment:
You can do it even shorter, view at my solution - it does work, too.
(And it does not have the limitation of max. n steps back)
...but anyway... thanks for your suggestion :-)
--- begin cut ---------------------
Public Class BasePage
Inherits System.Web.UI.Page


Default Protected Property item(ByVal varName As String) As Object
Get
item = Session(Me.GetType.FullName + "." + varName)
End Get
Set(ByVal Value As Object)
Session(Me.GetType.FullName + "." + varName) = Value
End Set
End Property


Private Property viewStateStorage() As Object
Get
viewStateStorage = item("viewStateStorage")
End Get
Set(ByVal Value As Object)
item("viewStateStorage") = Value
End Set
End Property


Protected Overrides Sub SavePageStateToPersistenceMedium(ByVal viewState As Object)
viewStateStorage = viewState
End Sub


Protected Overrides Function LoadPageStateFromPersistenceMedium() As Object
LoadPageStateFromPersistenceMedium = viewStateStorage
End Function
End Class
--- end cut -----------------------
Title: serialize?   
Name: Franz
Date: 2009-05-11 5:12:50 AM
Comment:
For what reason do you serialize / deserialize the viewState Object? You can store the viewState Object "as is" in the Session...
Title: RegisterHiddenField is obsolete   
Name: Shaggy
Date: 2009-03-13 12:29:09 PM
Comment:
For those of you who are attempting this, just note that the RegisterHiddenField method that is used in this sample is obsolete - particularly if you want to use this along with asp.net ajax or updatepanels. Instead, use:

ScriptManager.RegisterHiddenField
Title: Mr.   
Name: Paulo Zemek
Date: 2009-02-16 5:43:00 PM
Comment:
I have created a DLL for "caching" purposes that also solves the ViewState problem. I want to sell it, but for now I can send it without charge for testing purposes (but I already use it for a very long time with success).
Our serves had memory problems caused by the bad use of Session, and the viewstate itself never pleased me.
In my solution, I still keep ViewState, but my StatedPage has a State property.
It works similarly to ViewState, but data is kept at the server, be it on disc or on memory. I use timings to delete the files, and identical serialized object use the same file, which is "kept alive". I effectivelly do a hashset using the serialization information and directories.

This frees a lot of memory. Also, it is very fast because I reutilize files that weren't collected.
If you want to see, please send me an e-mail.
Title: Re: Naishal   
Name: Robert Boedigheimer
Date: 2008-12-31 8:02:32 AM
Comment:
Can you email me at robertb@aspalliance.com so we can discuss in more detail? Have you tried to use the ASP.NET built in server side viewstate? See how to configure at http://aspadvice.com/blogs/robertb/archive/2005/11/16/13835.aspx.
Title: System.AccessViolationException: Attempted to read or write protected memory   
Name: Naishal
Date: 2008-12-24 8:43:11 AM
Comment:
Hi Rob,
I am facing same issue, as mentioned by Sid in his post below, that too many times in a day. Sid, can you please let me know if you have tried out Rob's suggestion.

Rob, I would also like to know more about this problem inside out as it is a headache right now after migration to 3.5.
======================================================
Your article did wonder for us in 2006, now again after 2 years we are stuck after we upgraded our application source code from .net framework 1.0 to 3.5, on production we are getting errors in a viewstate code; written in BASE Page

[AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.]
System.Convert.FromBase64String(String s) +0
System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) +72
System.Web.UI.LosFormatter.Deserialize(String input) +11
MyWebUINamespace.BasePage.LoadViewState() +215
MyWebUINamespace.BasePage.LoadPageStateFromPersistenceMedium() +35
System.Web.UI.Page.LoadAllState() +43
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1661
Title: Solved- Session time out then bad viewstate   
Name: Carl
Date: 2008-12-23 2:29:24 PM
Comment:
This was happening because by default the website process got recycled after 20 minutes of inactivity and the machineKey was reset on the next post so the viewstate couldn’t be validated. Setting a static machineKey in the web.config fixed it, see http://forums.asp.net/t/955145.aspx?PageIndex=15. Thank you Robert for your help.
Title: Re: Carl   
Name: Robert Boedigheimer
Date: 2008-12-08 5:14:11 PM
Comment:
That seems really strange... There are lots of reasons why viewstate might be "invalid" based on how it is used, etc. I have never seen one that talks about authentication of it. The normal mechanism for viewstate is a hidden field stored in the page sent to the client, so when you post back for that page the server reads the viewstate information out of the hidden field and repopulates it for the controls. Email me at robertb@aspalliance.com directly and we can discuss some approaches you might want to take for this...
Title: Re: Carl   
Name: Carl
Date: 2008-12-08 1:30:23 PM
Comment:
Rob,
Thanks for the response and sorry I wasn't clear in my question. The viewstate is in the default configuration as far as I know, not kept on the server. http://msdn.microsoft.com/en-us/magazine/cc300437.aspx says “ViewState holds the state information for a single user, for as long as he is working with this ASPX page” but not for us. Any suggestions?
Title: Re: Side   
Name: Robert Boedigheimer
Date: 2008-12-08 9:29:35 AM
Comment:
You can try out the ASP.NET 2.0+ built in mechanism to see if it works for you. You can see how to configure at http://aspadvice.com/blogs/robertb/archive/2005/11/16/13835.aspx
Title: Re: Carl   
Name: Robert Boedigheimer
Date: 2008-12-08 9:28:55 AM
Comment:
If your session is lost or you don't allow cookies then the ASP.NET session state is not around to access your viewstate information. That is a basic problem with using session to store the viewstate. If you can't live with either of those you would need to store the viewstate somewhere else like a database or files. If you do that, you will have to worry about when to clean those up which is why the session is nice.
Title: Attempted to read or write protected memory   
Name: Sid
Date: 2008-12-08 1:40:54 AM
Comment:
Hi Rob,
Your article did wonder for us in 2006, now again after 2 years we are stuck after we upgraded our application source code from .net framework 1.0 to 3.5, on production we are getting errors in a viewstate code; written in BASE Page

[AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.]
System.Convert.FromBase64String(String s) +0
System.Web.UI.ObjectStateFormatter.Deserialize(String inputString) +72
System.Web.UI.LosFormatter.Deserialize(String input) +11
MyWebUINamespace.BasePage.LoadViewState() +215
MyWebUINamespace.BasePage.LoadPageStateFromPersistenceMedium() +35
System.Web.UI.Page.LoadAllState() +43
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1661
Title: Session time out then bad viewstate   
Name: Carl
Date: 2008-12-05 1:12:52 PM
Comment:
I ran across this article while researching a very similar problem we are having. We get the “Authentication of viewstate failed” error doing a postback after the session has timed out. We always get the error if cookies are disabled. Otherwise it's fine. 2 days of Googling and I haven't seen a solution for this. Yes increasing the session timeout and alowing cookieless sessions will fix, but what is happening? BTW this is on AspNet 1.1 and AspNet 2 pages
Title: Re: Blove   
Name: Robert Boedigheimer
Date: 2008-08-25 8:02:21 AM
Comment:
The fix you implemented is the proper one described in the article if you are using ASP.NET 1.1+ (2.0, 3.5, etc). ASP.NET 1.1 changed and caused the duplicate write of the "__VIEWSTATE" which renaming fixes. You will not have any problems once you rename it.
Title: Two viewstates now   
Name: Blove
Date: 2008-08-23 10:15:35 AM
Comment:
I followed the above code but now I'm getting two hidden viewstate tags in the html source. One has the viewstate number, which is expected, but the 2nd viewstate under it is blank. It looks like this:

{input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="2" /}
{input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="" /}

This is giving me corrupted viewstate errors obviously. What seemed to fix it is renaming the viewstate to __VIEWSTATE_SVR. But why am I getting this problem in the first place?? Will I have problems renaming it?
Title: Re: Tatiana O'Brien   
Name: Robert Boedigheimer
Date: 2008-04-21 8:05:48 AM
Comment:
Did you derive your code behind page from the base page class?
Title: _viewstate is still an encoded string   
Name: tatiana o'brien
Date: 2008-04-17 1:09:03 PM
Comment:
thank you for the great article. I have a question. I added the two files and made changes to web.config , but when I tested the page, I still see _VIEWSTATE being an encoded string instead of a request number. Am I doing something wrong?
Title: Re: Mario   
Name: Robert Boedigheimer
Date: 2008-03-06 5:09:17 PM
Comment:
When you use the server side viewstate method storing in session, the viewstate would be "deleted" when the session expires and ASP.NET reclaims the space used. By default, this is usually 20 minutes for inprocess session.
Title: Delete viewstate??   
Name: Mario
Date: 2008-03-06 3:48:42 PM
Comment:
when viewstate is deleted?
Title: Re: Mike Phelps   
Name: Robert Boedigheimer
Date: 2008-02-28 8:06:14 AM
Comment:
I worked with Manish in detail about his problem and I believe we came up with some options. Please email me at robertb@aspalliance.com and we can discuss.
Title: Problems with Ajax.net   
Name: Mike Phelps
Date: 2008-02-27 12:32:53 PM
Comment:
Hi Manish,

Did you ever find a solution to your problem? I am experiencing the same thing and I have no idea how to fix it. Thanks

Mike
Title: Problems with Ajax.net   
Name: Manish Patel
Date: 2007-08-07 9:26:19 AM
Comment:
Hi,

I have an aspx page that uses ajax.net, I have an update panel with many dropdown controls(say dropdown1 - dropdown10).

When a value is changed on dropdown1 I do a postback (taken care by the update panel) and then select certain values in the other dropdowns, however after ajax update or the values in the dropdown are lost.

This is bugging me, as i have other controls in the update panel that do not loose their values namely textboxes and checkboxes.

I also have dropdowns outside of the update panel that are not affected by this which is what you would expect as they are outside of the update.

Can you shed any light on this?

F.Y.I. in the aspx page attributes I have set.

EnableEventValidation="false"
EnableViewStateMac="false"
ViewStateEncryptionMode="Never"
ValidateRequest="false"

I have tried removing them all of the above have no affect apart from “EnableEventValidation” which causes an error about “The state information is invalid for this page and might be corrupted’

Thanks Manish
Title: Re: Ken   
Name: Robert Boedigheimer
Date: 2007-07-11 7:35:06 AM
Comment:
Now that basically the same solution is provided by ASP.NET 2.0, I would use it rather than use the solution as is above. The only reason I would consider doing my own now would be to leverage the compression classes available in .NET 2.0 (if I still needed to use hidden fields on the client at least it would be much smaller, or it can save server memory). I have not used the ASP.NET 2.0 solution in production yet, so I would do some stress testing to compare the two before we convert our site.
Title: Which solution is preferred?   
Name: Ken
Date: 2007-07-11 5:13:05 AM
Comment:
Hi Robert,

We are developing ASP.NET 2.0, I would like to know which solution is preferred, the on using hidden field or the one stated in here, http://aspadvice.com/blogs/robertb/archive/2005/11/16/13835.aspx?

TIA,
Ken
Title: Re: Lawrence   
Name: Robert Boedigheimer
Date: 2007-05-15 8:55:51 AM
Comment:
That is the behavior that ASP.NET has had with both 1.1 and 2.0, it creates the empty hidden element with the name "__VIEWSTATE" which is why you need to use another name in those versions (or you get duplicates). I am not aware of any way to remove it or what impact there would be if it was removed.
Title: Getting rid of the viewstate form field allthogether   
Name: Lawrence
Date: 2007-05-13 12:34:33 PM
Comment:
I'm interested in getting rid of the viewstate from the souce for an SEO purpose. Your code works brilliantly but in ASP.NET 2.0, it still leaves the __VIEWSTATE form fields in the source code. Why and is there a way to remove it.
Title: Reason   
Name: Chronologic
Date: 2007-04-12 8:14:50 PM
Comment:
>>"we were never able to determine why TCP did not detect the corruption"

I have had the same problem. What I think caused it for me was when users are running over a slow connection most browsers are or can be configured to start rendering a page before it's done loading. The page could therefore be posted back sometimes before the viewstate data was all sent because the user can click something and the browser will stop what it's doing and post back. I don't know for sure if that's why, but I know that my target audience is running on a slow connection using a slow browser (believe it or not) and in my tests if I would post back the page very quickly I'd get page validation issues. If I would wait patiently for the page to load before posting back, everything was fine. I ended up turning off page validation because it's not a public website and not that critical. The menu is at the top of the page and renders fast and people would be likely to click it if they wanted to navigate quickly to some other section.

Question I had when I saw this was: Does page validation only have to do with the viewstate? I'm not sure. If so what would be the point of it if the viewstate is in the session?

If the page validation is predicated upon a full page being sent and received every time it's pretty useless IMHO since that's not the way a lot of browsers work. I will say that it seems to work pretty well most of the time since many people have high speed internet and a fast computer at this point. But it still seems like a broken idea to me if I'm right about what I saw.

Just some thoughts I thought I'd add. Bye.
Title: Re: nimesh r patel   
Name: Robert Boedigheimer
Date: 2007-03-22 8:47:00 AM
Comment:
The role of the basePage class is used to replace the normal base page for all of the code behind files (System.Web.UI.Page) with a custom version so we can override the events that handle the viewstate. By overriding these methods, we can change how viewstate is stored by default (in a hidden field) to handle it however we like. By deriving all code behind classes from this class, they all use our new behavior. The purpose of the viewStateSvrMgr class is to manage storing the saved viewstates in a circular buffer so we store just the last X viewstate values. Please email me at robertb@aspalliance.com if you have any other questions.
Title: Respected Sir!( Actual working of the viewstate)   
Name: nimesh r patel
Date: 2007-03-16 5:04:45 AM
Comment:
Respected Sir ..
how actually the viewstate handled using the class whats the role of the class whats the dirty field and all the other properties is write at a time.

Thanks & Regards
Title: Re: Jeff Allan   
Name: Robert Boedigheimer
Date: 2006-12-04 11:11:19 AM
Comment:
Server side viewstate functionality is now built into ASP.NET 2.0 (see http://aspadvice.com/blogs/robertb/archive/2005/11/16/13835.aspx). The sample there is in C# as well but it is much smaller so it would be easy for you to convert. If you still want the .NET 1.x version of viewstate in VB.NET please email me at robertb@aspalliance.com.
Title: Very Nice!   
Name: Jeff Allan
Date: 2006-12-04 9:43:40 AM
Comment:
Hello, I am loading external pages into a label that is contained within a panel. I am now having view state issues. I think your article will help me. My project is a VS2005 VB application. Can I use the C# classes or should I convert to VB? If so, can you provide the VB version?
Thanks,
Jeff
jallan@wwnorton.com
Title: Re: Phil   
Name: Robert Boedigheimer
Date: 2006-10-16 8:26:05 AM
Comment:
Just place [Serializable] above the class definition like this:

[Serializable]
public class viewStateSvrMgr

in the viewStateSvrMgr.cs file.
Title: Persistent Sessions Problem   
Name: Phil
Date: 2006-10-13 6:27:12 AM
Comment:
I need to persist Sessions due th our application being hosted in a web farm environment. Unfortunately your solution gives the following .net error:

Unable to serialize the session state. Please note that non-serializable objects or MarshalByRef objects are not permitted when session state mode is 'StateServer' or 'SQLServer'.

Anyone any ideas on how I can store viewstate in SQL?
Title: User clicking   
Name: Scott Martin
Date: 2006-07-26 1:09:07 PM
Comment:
Corrupted viewstate can also be caused by users submitting a form multiple times without waiting for the original request to finish processing. The server becomes overloaded and begins to drop requests and portions of requests.

Adding scripting to disable submission elements on the form while a submit is in progress can alleviate the problem. It prevents multiple requests from stacking on the server and overloading the poor thing. Your approach of storing viewstate on the server will help as well, as the overall size of requests are significally reduced, thereby increasing the speed at which requests are received and processed by the server.
Title: Validators vs PageStateAdaptor   
Name: Anon
Date: 2006-06-08 12:45:50 AM
Comment:
I used the method mentioned here with DNN (www.dotnetnuke.com)
{
ASP.NET 2.0 now provides the server side functionality "out of the box", read my blog entry on how to do this at http://aspadvice.com/blogs/robertb/archive/2005/11/16/13835.aspx
}

However it caused the asp:RequiredFieldValidation controls on the site to have javascript errors, because the control started to add javascript to the page with the '-' character in it which caused the page to render with javascript errors on loading. It's a shame because it was working well until this happened.
Title: More help than I imagined!   
Name: MadPiano
Date: 2006-05-11 12:14:06 AM
Comment:
Thanks a million! I have an ASP.NET page loads other pages in an IFRAME and dynamically resizes the height - I found a trick for that online, but would get the "invalid/corrupted viewstate" error. These classes have made a world of difference and probably saved me a week of research and coding.
Title: Re: Supreeth   
Name: Robert Boedigheimer
Date: 2006-04-06 8:58:13 AM
Comment:
I setup a VS 2003 project that used the server side viewstate on Windows Server 2000 and it worked fine. I changed it to use the cookieless="true", I saw the request had the session embedded in it, and it still worked fine.
Title: Application Developer   
Name: Supreeth
Date: 2006-04-05 7:01:19 PM
Comment:
This article worked almost flawlessly until I came across this issue. The server side viewstate does not work if you use in a Cookieless browsers. The asp website considers every request as a new request and creates a new session eventhough it is the same session but with both session and persistent cookies disabled. I am using the exact same code and I am using SQL server to store the sessions. Any ideas??
Title: This is great   
Name: Isabelle
Date: 2006-02-03 2:00:58 PM
Comment:
This is a very good article and has solved a lot of problems that I had with previous viewstate sessions that I was using. Thank you very much Robert.
Title: Excellent   
Name: mohan
Date: 2006-01-30 5:21:23 AM
Comment:
mr.Robert Boedigheimer u r great, thnks, i was struck on this issue fortwo days, u helped me a lot.u r way of explanation is elegant . hope more from u. once again than
thnk u very much
Title: Thank you sooooooo much   
Name: Shanawaz Baig Mirza(India)
Date: 2005-12-21 8:47:30 AM
Comment:
Hi Robert,

I dont have words to express thanks to you for providing those two files for free download, i was struck with loads of issues becuase of the grid and its viewstate problem and your code files solved in just minutes.....:)

Indeed a really great and impressive article ....and keep it up,...
thanks a lot

regards,
___________________
Shanawaz Baig Mirza
India.
Title: Re: AsbjornM   
Name: Robert Boedigheimer
Date: 2005-11-16 8:28:51 AM
Comment:
I have the beta 2 version of ASP.NET 2.0 installed on my machine and it worked as expected when I setup a test version. Please email me at robertb@aspalliance.com if you need to discuss more.

ASP.NET 2.0 now provides the server side functionality "out of the box", read my blog entry on how to do this at http://aspadvice.com/blogs/robertb/archive/2005/11/16/13835.aspx
Title: Cool, but asp.net v2 crashed..   
Name: AsbjornM
Date: 2005-11-09 9:52:56 AM
Comment:
I'm getting "invalid viewstate" when running this on asp.net v2.
Title: Re: Tracey   
Name: Robert Boedigheimer
Date: 2005-11-07 7:54:31 AM
Comment:
Please email me at robertb@aspalliance.com so I can get your email address and I will send you the VB.Net version.
Title: VB.NET source   
Name: Tracey
Date: 2005-11-04 9:17:04 AM
Comment:
Hi Robert,
Interesting article and I would like to see the affect it has on my project which I'm currently trying to reduce the viewstate on - is there any possibility that you have a copy of the above in VB.NET?
Many thanks
Tracey
Title: VB.net   
Name: runar
Date: 2005-10-05 7:13:54 AM
Comment:
This article is brilliant. I'm struggeling with huge viewstate load on a w2k server, but this seems to be helpful. If any of you have successfully converted this to vb.net, can you email me? I just can't get it up and running.

Cheers
Runar B.

runar.broste
att
gmail.com
Title: VB.NET Version   
Name: Kevin Smith
Date: 2005-07-26 7:24:29 PM
Comment:
Hi Hilton Giesenow,

I would be very interested in the VB.NET version you have if you would be willing to share you code?

Look forward to your reply.

Kevin Smith
Email: kevin@netsmith.ltd.uk
Title: Re: Thabo   
Name: Robert Boedigheimer
Date: 2005-07-15 2:43:51 PM
Comment:
Email me at robertb@aspalliance.com and I can reply with some VB.Net source another reader provided
Title: Invalid character in Base-64 String   
Name: Thabo
Date: 2005-07-15 12:42:03 PM
Comment:
Thank you for a wonderful article.

I am currently encountering the Invalid ViewState error on a win2003 server running IIS6. I believe your solution will really help but I am not a C# programmer. I am battling to port the code to vb.net.

Can someone please help?
Title: Popup issue   
Name: Johannes Hansen
Date: 2005-07-13 7:06:00 AM
Comment:
Wouldn't the popup issue be solved by just letting the popup windows use the normal page-based viewstate? I guess this would be true for frames and iframes as well. Maybe another solution is to modify the code so it holds the last 5 viewstates for each of the last 5 visited pages. However, this would bring the total viewstate count the server will hold up to 25.
Title: Pop up issue   
Name: Ian
Date: 2005-05-24 10:59:02 AM
Comment:
Thanks for a useful article.
I found a problem with this method which is centered around popup windows (as some other people have found). The issue with pop-ups I found is that if the popup posts back to itself several time before the user returns to the original page then the viewstate value in session has been overwritten. Increasing the number of viewstates remembered can get around this problem but we have one instance of a popup that could potentially do a lot of postbacks before the user returns to the original page. I haven't tried it yet, but my solution to this I think will be to index the viewstates in session by the pagename as well as a history counter. If I limit the number of distinct pages that can be stored to 5 and a history for each of those pages of 3 (=> 15 distinct viewstates in memory at any one time for a single user) then this should solve the popup problem.
Title: Multi-Window problem   
Name: Anthony
Date: 2005-04-28 10:30:20 PM
Comment:
hey sorry my bad. i just solved my issue in the previous post.
i had the calender date picker window inherit from you base class rather than inheriting from the System.Web.UI.Page class.
obvious tip. make sure this tool is only applied to pages that need it so be careful when using a page template
Title: Multi-Window problem   
Name: Anthony
Date: 2005-04-28 9:42:44 PM
Comment:
this is a great article. however i am also getting the same issue as Eric with the multiple windows. in my case im using a pop-up windows to show a calender. when i go back to the original page the Page.IsPostBack get set to false when all i have done is use a pop-up calender window.
Title: Super Duper!   
Name: Cameron D
Date: 2005-04-26 2:30:18 AM
Comment:
Brilliant article. I too ported it to VB.Net and took my main page from 140KB to 79KB. Using the Cache gave it a real boost, as I store Session state on a SQL server. Our customers love it!
Title: So greate!   
Name: Leo Wong
Date: 2005-04-14 2:40:47 PM
Comment:
Hi,Robert.It sound so wonderful!We also come across the same problems with VIEWSTATE previously.Your idea should be
a greate solution.I am just going to try it.
Thanks for your work!
Title: Multi-Window problem   
Name: Eric
Date: 2005-02-15 11:16:30 AM
Comment:
I am having one problem that I would like to run by you. My app is a multi-window web application. The main window has a grid and users can double-click on the grid (I've added ondoubleclick events to the grid items) to open a new window with the detail view.

The serverside viewstate works great until they have more than one detail view open at the same time:

detail.aspx?id=1
detail.aspx?id=2

When I open 1, then open 2, if I switch back to 1 and do a post back it seems as though it has to refresh it's viewstate so I end up having to do the postback twice to get the desired result. I am using .NET 1.1
Title: Trying to store in a file but losing state   
Name: Joseph Gama
Date: 2004-12-21 3:12:54 PM
Comment:
Hi Robert,
Great article! This is very important info and it is explained in a very practical way, very easy to understand.
I am actually using Dr. Bromberg's expansion of this idea to use cache, memory globals, etc. as alternatives to session:
http://www.eggheadcafe.com/articles/20040613.asp
However, I had to serialize the class so that it would allow me to save the data to a file or even compress it. These two cases always result in losing state.
Please let me know if you have any suggestions.
Thank you,
Best regards,
Joseph Gama
Title: Re: Hilton Giesenow   
Name: Robert Boedigheimer
Date: 2004-11-09 5:12:38 PM
Comment:
Can you email me at robertb@aspalliance.com so we can discuss in more detail the issues you are having?
Title: Randomly losing viewstate   
Name: Hilton Giesenow
Date: 2004-11-09 7:56:02 AM
Comment:
Hi Robert. This idea looks interesting. I've also ported to vb and am testing and I'm getting some strange quirks. First of all, I found that with an iframe in a page things can go screwy on the parent. Also, I find that it seems to be randomly losing the viewstate.
Title: Impressive   
Name: Xybex
Date: 2004-08-27 8:29:42 AM
Comment:
Thank you for a great article, and Robert, this works wonderfully! I ported the code to vb.net and implemented it into a production application. We haven't had a single incident with it. Once again thank you.






Community Advice: ASP | SQL | XML | Regular Expressions | Windows


©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-03-28 2:53:17 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search