Question

Let's say you have a aspx page that does not rely on session, but does rely on viewstate for persistance between postbacks.

If a user is accessing this page, and leaves for a long lunch, will viewstate still be valid when he returns?

Was it helpful?

Solution

No ViewState is kept as part of the PostBack process. You can, however, override the Page class's SavePageStateToPersistenceMedium() and LoadPageStateFromPersistenceMedium(), to implement that behavior if desired. For more information read Understanding the ASP.NET ViewState.

Note that Page ViewState is stored in the Session so if your Session expires, the ViewState will be lost. I wouldn't say this is ViewState expiring, but yes, it will be destroyed after Session timeout.

OTHER TIPS

Viewstate itself does not expire. Since it's posted back in a form, it can be reconstituted any time.

According to MSDN: "...it is possible for view state to expire if a page is not posted back within the session expiration time". So, in a round about sort of way, it can expire if your session does, but viewstate does not directly expire. Since you're not using session state anyway, you don't have to worry about implicit expiration.

Note that I wouldn't have said it expired. That was MS who I quoted in their own article entitled Controlling ViewState

Viewstate does not expire.

All viewstate data is stored on the client and is submitted back to the server when the user executes a postback.

This has some very interesting implications, and is explained very thoroughly here.

Also, as a gotcha, by default ASP.NET encrypts ViewState with an autogenerated key. This can be overridden with the MachineKey element in the web.congif file. Even though ViewState won't expire, it can become invalid if a different autogenerated key is used to decrypt ViewState, such as after an IIS Reset, redeploying an application, or hitting a different server in a web farm. If you're planning on storing viewstate for long periods of time, watch out for how it's encrypted/decrypted.

http://msdn.microsoft.com/en-us/library/ms998288.aspx

Yes, ViewState expires in certain conditions. For example when you are using iframe:s, or when you are upkeeping "live" connection to the server with regular postbacks. Then you might want to investigate this option: <sessionPageState historySize="9"/>, which actually hard-codes how many "postback results" are stored in the Session (if SessionPageStatePerster is used). Each postback stores it's ViewState to the end of the Queue in Session["__VIEWSTATEQUEUE"], and deletes ViewStates that are "too old". And how do you think SessionPageStatePerster decides which ViewStates are too old.. by configuring some arbitrary historySize-constant in web.config.. Omg! It too me forever to find this problem... My hatred toward asp.net programming is undescribable now.. grrr...

Viewstate does not expire, as long as they are still on the page, it will still be there and functional.

The ViewState will persist from POST to POST. It's actually stored inside a hidden field on your form so that it gets POSTed back to your server all the time.

As long as you aren't relying on the Session you shouldn't have any problems rebuilding page state. It's easy to test your Page's state code if you want though: just set your session to expire after 60 seconds in your web.config then load your page, wait a little more than a minute (surf over to Stack Overflow and answer some questions) and then click a button on your page.

Sorry to relive this old thread, but new information is available now:

Yes, ViewStates expire. I come from 19 hours researching about a problem of ViewStates losing its values between long time interval postbacks. It took me a while reading MSDN documents and Stackoverflow answers saying it was basically impossible to happen unless a custom ViewState storage implementation was employed, which, now I know, it's not true.

My problem was taking place in a SharePoint 2013 environment. The service known as Distributed Cache (a.k.a. AppFabric) does the caching of the ViewState and has a Time to Live associated to it. You can find more information here: http://blogs.msdn.com/b/besidethepoint/archive/2013/03/27/appfabric-caching-and-sharepoint-1.aspx

The interesting bit of information can be found in this phrase: "To improve page performance, beginning in SharePoint 2013 SharePoint caches ViewState data server-side rather than transferring it back and forth to clients."

I hope this information helps somebody so desperate as I was 19 hours ago.

ViewState is kept in a hidden field on the page itself. So as long as the user has the page, he'll have the ViewState. But if your app automatically logs the user out after a certain period of time, still having the ViewState may not do him any good.

By default, Viewstate is included with the html content as a hidden input. That means it won't expire, but that everything in viewstate must be uploaded from the user's browser. Since that's typically the slowest part of the connection in a public site, putting a lot of stuff in viewstate can quickly make your site seem very slow.

The short answer is: no.

The longer answer is: it depends on implementation of ViewState storage. You can provide custom implementation of ViewState which could expire after given amount of time. For example, you could store ViewState in database or on disk and send only some reference to the stored value in a hidden field. Then you can use batch processing to remove outdated ViewState data or perform expiration upon request.

No Viewstate doesnot expires.After redirecting to other page then value of view state lost or expire viewstate. for more detail http://www.c-sharpcorner.com/UploadFile/78d182/Asp-Net-state-management-techniques/

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top