Viewstate management in ASP.Net 4.0

In ASP.NET 4.0 we have some very interesting new enhancements and new features.

I will try to talk about all of them in separate posts.

In this post I will talk about Viewstate management in ASP.NET 4.0.

Let’s have a look first what really Viewstate is and what it really does.Unless you move to a new paradigm for building web applications like ASP.NET MVC you must have a good knowledge of Viewstate.

Viewstate represents the state of the page when it was last processed on the server. We use it to retain values across two successive requests for the same page. It is a hidden field added to the page and is restored on the server before the page request is processed. The Viewstate information travels back and forth with the page itself, but contains no visual elements that need to be rendered. So you must be thinking that this is fantastic news for the web developer. But (there is always a but), the extra information in the Viewstate adds to the size of the page and the information that travels down the wire. I have seen web pages that have an additional 20Kbytes of Viewstate information.

Every .aspx page derives from the Page class or Page control and extends it. The default value for the EnableViewState property for the page is True. Through that property we can get or set(enable-disable)  the view state of the control. However, EnableViewState property is ignored for child controls. So if we have EnableViewState=True for the page, which is True by default, all the child elements on that page will have EnableViewState=True for their viewstate property. So if we type this  txtname.EnableViewState = false , this will have no effect, since the textbox is the child of the .aspx page we are designing.

There is a mistake here. The opposite is actually true.If we disable ViewState on page level, you cannot enable it on child controls. if you go to the web.config and type

<pages enableViewState="false">

then if you try to enable it on child controls is impossible.

So to be absolutely clear, in 1.1, if you have ViewState enabled on page level , you can have it disabled for some controls you choose.

But if you disable it on page level(or application level) you cannot enable it for individual controls.

See an example below(in the comments section written by Richard).

Credit and kudos to Richard  for pointing that out and correct me. Thanks Richard!!!!!

In ASP.NET 4.0 we have the ViewState property. There are 3 values for this property:enabled, disabled, inherit .

We can use this property to enable Viewstate for an individual control even if Viewstate is disabled for the page. We can disable the Viewstate for a control even if it is enabled on a page level.


  • "EnableViewState property is ignored for child controls. So if we have EnableViewState=True for the page ... all the child elements on that page will have EnableViewState=True"


    You've made the same fundamental mistake as Dino [1]. If ViewState is DISABLED on the parent, it cannot be ENABLED on any child - not the other way round.

    The documentation is quite clear on this. Looking at the source code confirms it. It is also trivial to create a sample to prove it.


  • "EnableViewState property is ignored for child controls. So if we have EnableViewState=True for the page, which is True by default, all the child elements on that page will have EnableViewState=True for their viewstate property."


    Don't believe everything Dino writes. If ViewState is DISABLED on the parent, it cannot be ENABLED on the child. If it is enabled on the parent, it can still be disabled on the child.

  • Good news about this new ViewState behaviour.

  • You are wrong. Ignoring comments that disagree with you won't change that fact.

  • @Richard: Richard, who is ignoring your comments? where do you disagree? and who is Dino?

  • Richard,your comments, were sent yesterday.... i am not monitoring my weblog 24 hours per day. if i am mistaken i will be happy to correct it and give appropriate credits to you. I learn new things every day and i do not claim i know everything that goes on the world.thanks

  • And now you can see the problem - I replied three days ago, but it hasn't appeared yet. At this point, I have no way of knowing whether my reply is waiting for approval, has been deleted, or even whether it got through in the first place.

  • Richard, the moment i see a comment that does not contain offensive content, i approve it immediately. if you do not see a comment of yours in this list, it must have been caught by spam. I will always publish all comments and i will publish yours of course. feel free to contact me via email.thanks

  • So it was deleted? Why?

  • Richard, i am publishing all your comments. are you sure it is not here? when i go to my control panel, i see no comments unpublished.... i have not deleted it, but if you say you sent something that is not in the comments list....can you please post it again?

  • I replied to your comment on 20th October. It hasn't shown up, so it must have been lost in the system somewhere. This is one of the most annoying features of the ASP.NET blogs - between posting a comment and the blog owner approving it, you have no way of knowing what's happened to it.

    I thought you were ignoring me because I saw the two comments posted after mine had been approved when mine had not. I accept that my comments were probably buried in a list of spam, and I apologize if my last comment seemed a bit aggressive.

    I disagree with your statement that ViewState enabled for the page implies ViewState enabled for all descendants. In fact it is the other way round - ViewState disabled for a parent implies ViewState disabled for all descendants. The documentation is quite clear, and a trivial example will confirm this.

    The "Dino" I referred to is Dino Esposito. He made the same mistake in his blog post (see the link in my first comment) and his September MSDN Magazine article. He has yet to respond in any way to the comments pointing out his mistake, which I find inexcusable for such a highly visible Microsoft employee.

    Here's hoping that this comment makes it through intact!

  • which version of you use? 2,0 or 3.5?

  • what happens if you take
    if (!IsPostBack) out?

  • This works the same on 1.0, 1.1, 2.0 and 3.5; the implementation of ViewState hasn't changed much over the years.

    If you take out the "if(!IsPostBack)" line, both controls remain green, but the ViewState size remains the same.

  • richard you are right. i must have been looking on the wrong column. I am correcting the post

Comments have been disabled for this content.