Scott On Writing.NET : ASP.NET View State

Determining an ASP.NET Page's View State Footprint

Scott Mitchell — Tue, 06 Jul 2010 19:35:00 GMT

ASP.NET view state is the technique used by an ASP.NET Web page to persist changes to the state of a Web Form across postbacks. The view state of a page is, by default, placed in a hidden form field named __VIEWSTATE, and can easily get very large. Not only does the __VIEWSTATE form field cause slower downloads, but, whenever the user posts back the Web page, the contents of this hidden form field must be posted back in the HTTP request, thereby lengthening the request time, as well. Because view state is buried in a hidden form field and because as developer we typically test locally, the affect of view state bloat on the user experience requires preemptive action. Steps must be taken to measure view state's size and to take steps in trimming down view state if it begins to negatively affect the user experience.

There are a variety of techniques for measuring the view state size on a given page. Perhaps the simplest is to turn on page tracing. With page tracing enabled you can see the estimated view state of each control in the control hierarchy. For instance, the screen show below shows that two Labels on my page consume (roughly) 120 bytes of view state each.

There's also a free add-on for Firefox that reports view state size directly in your browser window: Viewstate Size. When installed, this add-on will show a little icon in your browser's lower right corner reporting the view state size for a given page.

It's also possible to determine the view state size programmatically. Today I was working on a demo for an article and wanted to have the view state size displayed on every page. After reading an article I wrote back in 2004 - Understanding ASP.NET View State - I came up with the following code snippet to compute and display the view state size for a given page. This technique uses the "old school" way of doing it, relying on objects that have been around since ASP.NET's inception. Consequently, the below code will work in any ASP.NET application.

Visual Basic Version:

Protected Overrides Sub SavePageStateToPersistenceMedium(ByVal state As Object)
    MyBase.SavePageStateToPersistenceMedium(state)

    Dim formatter As New LosFormatter()
    Dim viewStateLength = -1

    Using writer As New StringWriter()
        formatter.Serialize(writer, state)
        viewStateLength = writer.ToString().Length
    End Using

    Response.Write(String.Format("<h1 class="" viewstate-summary="">Total ViewState Size For This Page: {0:N0} bytes</h1>", viewStateLength))
End Sub

C# Version:

protected override void SavePageStateToPersistenceMedium(object state)
{
    base.SavePageStateToPersistenceMedium(state);

    var formatter = new LosFormatter();
    var viewStateLength = -1;

    using (var writer = new StringWriter())
    {
        formatter.Serialize(writer, state);
        viewStateLength = writer.ToString().Length;
    }

    Response.Write(String.Format(@"<h1 class="" viewstate-summary="">Total ViewState Size For This Page: {0:N0} bytes</h1>", viewStateLength));
}

The approach overrides the SavePageStateToPersistenceMedium method, which is what is invoked when the page is ready to persist its view state. In ASP.NET 1.x you would override this method to store view state to an alternative store, such as to a file on the web server, rather than in a hidden input field on the form. Starting with ASP.NET 2.0 you could use the PageStatePersister class. However, here I just want to compute the size of the serialized view state string. Consequently, I start by calling the base class's SavePageStateToPersistenceMedium method. Next, I replicate the default logic that the ASP.NET Page class uses to serialize view state - namely, I create a LosFormatter object and serialize the content to a StringWriter. Once I've done this I can determine the size of the persisted view state by getting the StringWriter's contents and determining how many characters are included. The above code can be placed directly in a code-behind class or, better yet, in a custom base Page class.

The above programmatic approach is relatively easy to implement and works in all versions of ASP.NET. However, it won't produce the precise view state size for ASP.NET 2.0 applications and beyond. This is because the LosFormatter class was replaced with a new formatting type, ObjectStateFormatter, starting in ASP.NET 2.0. (You can certainly use the LosFormatter code above in ASP.NET 2.0 and beyond applications, as the class remains in the framework for backwards compatibility. Granted, the reported view state size and actual size will differ slightly, but in analyzing whether a page contains too much view state or not, precise numbers aren't required - a close estimate will usually suffice.)

To get precise measurements we can use the ASP.NET 2.0+ by doing the following:

Create a class that extends the HiddenFieldPageStatePersister class. This is the class that is used by ASP.NET (by default) to persist view state and other information to hidden form fields. We want to extend this class to include a property that reports the size of the persisted state, and
Override the Page class's PageStatePersister property and return the custom persister class created in step 1.
Override the Page class's SavePageStateToPersistenceMedium method and read the value of the view state size from the class created in step 1.

Here's the code for the class that extends HiddenFieldPageStatePersister, which I've named MyHiddenFieldPageStatePersister (please don't mock me for my lack of naming creativity). This class is pretty simple: it defines a property named StateSize, overrides the Save method, and then sets the StateSize property from this method using the same code/logic as used internally by the HiddenFieldPageStatePersister class. The code snippet below takes advantage of some language features that you might not have at your disposal if you're using an older version of C# or VB (for example, the use of automatic properties). But the concept is sound and should work (with a little tweaking) in earlier versions of VB/C#. (I tested this using ASP.NET 4. You can download the complete source code here.)

Visual Basic Version:

Public Class MyHiddenFieldPageStatePersister
    Inherits HiddenFieldPageStatePersister

    Public Sub New(ByVal page As Page)
        MyBase.New(page)
    End Sub

    Public Overrides Sub Save()
        If MyBase.ViewState IsNot Nothing OrElse MyBase.ControlState IsNot Nothing Then
            Me.StateSize = MyBase.StateFormatter.Serialize(New Pair(MyBase.ViewState, MyBase.ControlState)).Length
        End If
        
        MyBase.Save()
    End Sub

    Public Property StateSize As Integer
End Class

C# Version:

public class MyHiddenFieldPageStatePersisterCS : HiddenFieldPageStatePersister
{
    public MyHiddenFieldPageStatePersisterCS(Page page) : base(page) { }

    public override void Save()
    {
        if (base.ViewState != null || base.ControlState != null)
            this.StateSize = base.StateFormatter.Serialize(new Pair(base.ViewState, base.ControlState)).Length;

        base.Save();
    }

    public int StateSize
    {
        get;
        private set;
    }
}

The last step, then, is to override the Page class's PageStatePersister property and return an instance of our persister class, MyHiddenFieldPageStatePersister. Again, this can be done in the code-behind class of an ASP.NET page, but I recommend putting it in a custom base Page class.

Visual Basic Version:

Private _PageStatePersister As PageStatePersister = Nothing

Protected Overrides ReadOnly Property PageStatePersister As System.Web.UI.PageStatePersister
    Get
        If _PageStatePersister Is Nothing Then
            _PageStatePersister = New MyHiddenFieldPageStatePersister(Me)
        End If

        Return _PageStatePersister
    End Get
End Property

C# Version:

private PageStatePersister _PageStatePersister = null;

protected override PageStatePersister PageStatePersister
{
    get
    {
        if (_PageStatePersister == null)
            _PageStatePersister = new MyHiddenFieldPageStatePersisterCS(this);

        return _PageStatePersister;
    }
}

EDIT [2010-07-07]: I forget an important final piece of the puzzle for using the MyHiddenFieldPageStatePersister class! In addition to overriding the PageStatePersister property you also need to override the SavePageStateToPersistenceMedium method like in the LosFormatter example, but instead of using LosFormatter you need to read the value of the StateSize property from the MyHiddenFieldPageStatePersister class. The code for this overridden method follows:

Visual Basic Version:

Protected Overrides Sub SavePageStateToPersistenceMedium(ByVal state As Object)
    MyBase.SavePageStateToPersistenceMedium(state)

    Dim myPersister As MyHiddenFieldPageStatePersister = CType(Me.PageStatePersister, MyHiddenFieldPageStatePersister)

    Response.Write(String.Format("Total ViewState Size For This Page: {0:N0} bytes", myPersister.StateSize))
End Sub

C# Version:

protected override void SavePageStateToPersistenceMedium(object state)
{
    base.SavePageStateToPersistenceMedium(state);

    var myPersister = this.PageStatePersister as MyHiddenFieldPageStatePersisterCS;

    if (myPersister != null)
        Response.Write(String.Format(@"Total ViewState Size For This Page: {0:N0} bytes", myPersister.StateSize));
}

Happy Programming!

How Big is Too Big a ViewState?

Scott Mitchell — Wed, 07 Sep 2005 13:14:00 GMT

When creating ASP.NET pages one thing that usually doesn't get looked at too intensely by developers is the page's ViewState weight (I've been guilty of this myself). While there are various mechanisms to reduce the ViewState bloat in a page, the ultimate (uneloquently worded) question is, “How big is too big a ViewState?” Dino Esposito chimes in with some metrics in his blog entry ViewState Numbers [emphasis Dino's]:

You should endeavour to keep a page size around 30 KB, to the extent that is possible of course. For example, the Google’s home page is less than 4 KB. The home page of ASP.NET counts about 50 KB. The Google’s site is not written with ASP.NET so nothing can be said about the viewstate; but what about the viewstate size of the home of the ASP.NET site? Interestingly enough, that page has only 1 KB of viewstate. On the other hand, this page on the same site (ASP.NET) is longer than 500 KB of which 120 KB is viewstate.

The ideal size for a viewstate is around 7 KB; it is optimal if you can keep it down to 3 KB or so. In any case, the viewstate, no matter its absolute size, should never exceed 30% of the page size.

I think these are good metrics to live by when building apps targetted for the Internet. ViewState enacts a “double hit” regarding page load time. First, the user must download the ViewState bytes. Then, when posting back, that same ViewState must be reuploaded to the web server (sent back in the POST headers). And then, when receiving back the resulting markup from the postback, the ViewState (possibly modified) is sent back down again. So during a postback there's a seemingly double hit. That is, if it takes x seconds to download the ViewState of the page, when the user posts back it will take at least 2x - x to upload the ViewState and another x to download it back again. Cripes! (This is part of the reason AJAX is so appealing in Internet situations, although AJAX carries with it it's own slew of issues.)

When you're building intranet apps, where you know your user's will be connecting over a LAN, the page sizes and ViewState sizes are not as important as they impact the user experience much less. Most of my “real-world” projects have been created for the intranet setting, so I've not had to fret over ViewState size as much as others may have.

For those projects where a trim ViewState size is paramount, one common question is how to quickly determine the ViewState size (and, perhaps, what junk is actually being stored in there). For the ViewState size, I usually just do a View/Source and then highlight the ViewState content. (In UltraEdit - my text editor of choice - the number of bytes selected is shown in the toolbar.) To determine the contents of ViewState there are tools like Fritz Onion's ViewState decoder (for ASP.NET 1.x and 2.0) and Nikhil Kothari's Web Development Helper (for 2.0). I also provide code for a web-based ViewState decoder (for ASP.NET 1.x) in my article, Understanding ASP.NET ViewState.

Don't Trust ViewState

Scott Mitchell — Tue, 03 May 2005 21:03:00 GMT

Today I was pointed to a recent email to the BUGTRAQ mailing list (a mailing frequented by security experts) concerning replay attacks and ASP.NET view state. The email was posted by Michal Zalewski, titled: ASP.NET __VIEWSTATE crypto validation prone to replay attacks. As I describe in my article Understanding ASP.NET ViewState, The contents stashed in the hidden __VIEWSTATE form field are base-64 encoded and (by default) cryptographically signed to prevent view state tampering by a malicious client and ensure validity of the view state's contents across postback.

The signature occurs by salting the view state with both the HashCode for the virtual directory in which the page exists along the page's HashCode. This signature prevents a nefarious user from modifying the view state and posting it back. If such a situation unfolds, the ASP.NET runtime will not that the reposted view state's signature does not match up and throw an exception. Similarly, this mechanism prevents against replay attacks where the view state is taken, without modification, and posted back to a different page. Since the view state is signed by the page's HashCode, the signature wouldn't match up.

What Michal reasoned out, though, was that the view state was vulnerable to replay attacks to the same page. His example is a common one: you have an eCommerce site where the data loaded on the page is dependent upon querystring parameters, such as GetProduct.aspx?ID=productID. If things like price are stored in the view state (such as in a shopping cart DataGrid or put there programmatically), a frugal visitor could visit GetProducts.aspx?ID=cheapProduct, save the view state in the hidden form field, then repost that to GetProducts.aspx?ID=expensiveProduct. The end effect might be that the user could order the expensive product for the price of the cheap one. (Of course this would only be possible if the eCommerce site relied solely on the view state for pricing information when computing the final bill.)

The point is, don't trust view state (or the data that is put there by Web controls, such as the DataGrid). That is, if you have important information, such as pricing data, it's OK if it is placed in view state (such as in a row in a DataGrid), but don't grab the pricing data to charge by just poking around the view state (as in programmatically accessing the contents of a DataGrid). Instead, if you need to get pricing information (or any other important bit of information) for the final order processing, it is imperative that you requery the database.

Another point Michal made in his email was that view state can be used in a one-click attacks. That is, a nefarious hacker could pass along one view state through a third-party, the end effect being that the third-party sees a page with a view state they did not “create” themselves. Michal points out that to avoid this there needs to be someway to associate the view state with information particular to a user. This is possible in ASP.NET 1.1 via the ViewStateUserKey property, which is an additional, optional parameter that is used as a salt in the signature. You can assign this property to some unique user value to prevent the attack; see Improving Web Application Security: Threats and Countermeasures for more information.

The last point of Michal's email to BUGTRAQ was concerned unsigned view states. If you opt not to sign the view state (that is, if you set EnableViewStateMac to false), ASP.NET naively attempts to decode the view state passed in. This can be used as a denial of service vector by dumping in a very large hidden view state field, which can severely hamper the performance of the web server. (Of course, the web server is likely configured to reject any incoming request that's larger than 4 MB in size, but this is still an easy point of attack since crafting and posting a large view state is a trivial task from the attacker's point of view.) To protect yourself from this don't set EnableViewStateMac to false, if possible. There have been some claims that you need to set EnableViewStateMac to false in order to have Server.Transfer work properly. There is a workaround, as discussed in this KB article. It is my understanding, however, that you'll need to set EnableViewStateMac to false if you are using a web farm without server affinity.

I followed up Michal's email to BUGTRAQ with an offlist discussion. His main point, as I understand it, is that he in concerned because developers might think that view state is a safe place to put sensitive data or data that need not be revalidated due to the signing/encrypting options view state provides. However, as Michal's email shows, view state - even signed and/or encrypted view state - is not safe from replay attacks on sites where a single page's differs merely by the querystring. The short of it - don't trust that your view state information has not been modified and always requery the database before using information whose correctness is important.

Using Email as a Knowledge Base

Scott Mitchell — Tue, 26 Apr 2005 01:42:00 GMT

A recent BBC article, E-mail is the New Database, examines how as the storage capacity and search capabilities of email services have grown and improved over the past year, many folks are using their online email accounts as personal databases. Need to remember and be able to find that colleague's phone number from anywhere in the world? Email his contact information to your GMail account. Want to be able to puruse your TODO list at work? Email it to your GMail account before you leave home in the morning.

Anywho, this article got me to thinking - why not use GMail as an online knowledge base? I've already blogged before about the usefulness of GMail for managing high-volume listservs - with its threaded email views, virtually unlimited storage space, and killer search features it's makes email listservs enjoyable to use again. So why not create a GMail account that does nothing else but serve as a repository for a gaggle of focused email listservs? Over time this GMail account would automatically be populated with user's questions and (more importantly) answers to these questions. When facing a particularly tough problem, the first stop - before searching the web, would be to logon and search this GMail account. It would be like searching a small corner of the web that was known to be highly focused on,.say, server-side development using Microsoft technologies.

On Sunday I created a new GMail account and started signing up to ASP.NET-related listservs. There are a number over at ASPAdvice.com along with a number over at Yahoo! Groups. What's also neat is that the ASP.NET Forums allow you to receive an email whenever a new post is made to a specified forum. Similarly, you can configure Google Groups to send you a daily digest from a particular USENET newsgroup (such as microsoft.public.dotnet.framework.aspnet).

With these data sources alone, I've already amassed 417 “conversations” from around the web, highly focused on ASP.NET development. (These numbers boil down to an estimated 12 new conversations per hour; meaning in a month, there'd be roughly 8,000 conversations, or 86,000 in a year. The nice thing is that this archive can be quickly searched just as well as the web is searched through Google and space will (likely) never be an issue.). I've yet to need to search this GMail account for technical help, but I am expecting/hoping to find it to be: (a) easy to search, and (b) more relevant than a general web search via Google, especially since many of these resources (especially listservs) are not archived on a website, and therefore not indexed by Google's spiders. (I'll keep you posted as to how useful such a GMail account turns out to be...)

Another neat use for GMail! BTW, if you need a GMail account, feel free to drop me a line, I'd be happy to hook you up.

Control Building and ViewState Redux

Scott Mitchell — Fri, 08 Oct 2004 12:35:00 GMT

Earlier this week I posted an entry titled Control Building and ViewState Lesson for the Day, in which I discussed when working with dynamic controls the importance of the order with which a control is added and its properties are set. My end recommendation was to use the following pattern:

Create an instance of the control (i.e., TextBox tb = new TextBox();)
Add the control to the appropriate Controls collection (i.e., PlaceHolderID.Controls.Add(tb);)
Set the dynamic control's properties (i.e., tb.ForeColor = Color.Red;)

The key lesson was to make sure you do step 2 before step 3, or you may be plauged with view state issues. In that previous blog entry I mentioned that the reason this happens is because if the control is added after the TrackViewState stage in the page lifecycle (such as in the Load stage), then any changes to the control's properties are not recorded by view state, so nothing gets saved to view state and so nothing on postback gets populated back into the control's view state. However, I said that adding a control via the Controls.Add() method causes the controls TrackViewState() method to be called. This is correct, but it's not a complete answer.

Not only is the TrackViewState() method being called for the added control, but it goes through the entire control lifecycle, if needed. Using Reflector you can see that the control's InitRecursive() method is called, which fires the Init event for the added control and all of its children controls (this also is where the control's TrackViewState() method is invoked). If the control that is having the dynamic control added to it has a non-null ViewState, the control being added has it's LoadViewStateRecursive() method called, which loads the view state into the added control and its child controls. But things don't end there necessarily. If the control that had the dynamic control added to it has already fired its Load event, the added control's Load event is fired (recursively, again), and even the PreRender event is fired if needed.

One final point to clear up: in my previous blog entry I credited Alex Lowe with being the one whose words from 2001 had reminded me that I needed to add the control first and then set its properties. Memory's a funny thing, really, since I remembered Alex's words, but I had totally blanked on an email Wessam Zeidan had sent me in late September 2004 where he talked about the same thing, saying: “... some how when we add a dynamic control to the Controls collection, the TrackViewState method gets called, and that explains why the backcolor property of the textbox gets saved to the viewstate if we add the textbox to the controls collection before setting it.” And if that wasn't enough, I realized that I said the same thing myself in my MSDN article Understanding ASP.NET View State:

You may be able to get away with loading your controls in the Page_Load event handler and maintaining the view state properly. It all depends on whether or not you are setting any properties of the dynamically loaded controls programmatically and, if so, when you're doing it relative to the Controls.Add(dynamicControl) line. A thorough discussion of this is a bit beyond the scope of this article, but the reason it may work is because the Controls property's Add() method recursively loads the parent's view state into its children, even though the load view state stage has passed.

It's funny how our minds work, and how fluid memory can truly be.

Control Building and ViewState Lesson for the Day

Scott Mitchell — Wed, 06 Oct 2004 19:17:00 GMT

Whenever I am working on a problem and hit a perplexing roadblock that impedes my process, my initial emotional state is calm. “I'll figure out this problem soon,” I tell myself, as I explore workarounds or examine the code base to try to understand why I can't do what I know I should be able to do. If this search goes on for five or more minutes, I start to get a little flustered. Off to Google!” I declare, hoping there has been some other unfortunate soul who has experienced the same problem and has shared his solution. I usually hit the Google Web search first and, if I have no luck there, I delve into the USENET postings on Google Groups. If 15 minutes have passed with no hits from Google, I start to get angry at myself. “I SHOULD KNOW HOW TO FIX THIS,” I say, as I pour back over the material I examined in the first five minutes, knowing there must be somethinig I overlooked. What's interesting is that if this search continues into, say, the half hour mark, my emotions start to sway from frustration and despair to glee. “Wait until I figure out what went wrong,” I reason, “and I can share it on my blog, and it will help others down the road.” And that's what keeps me going.

Today's lesson - which will hopefully save you the 40 minutes it cost me - centers around composite controls, the DropDownList Web control, and ViewState. Let's say you want to create a composite control that contains a DropDownList that already is bound to database data (namely, it does not allow the control developer to specify the DropDownList's DataSource as would normally be the case: for a discussion on the pros and cons of this approach check out Composite Controls That Do Their Own DataBinding by Andy Smith). If you are at all like me, you're composite control's code would look like this (WARNING: this is wrong):

public class MyControl : WebControl, INamingContainer
{
...

protected override void CreateChildControls()
{
DropDownList ddl = new DropDownList();
if (!Page.IsPostBack)
// do data binding to some database...

Controls.Add(ddl);
}
}

This, as aforementioned is the WRONG WAY to do it. Why? Well, give the control a whirl by creating an ASP.NET Web page with this control and a Button Web control. When you visit the page the first time, the DropDownList is displayed, populated with the database data. However, if you click the Button and the page posts back, the items in the DropDownList disappear - the DropDownList is not saving its view state.

If you're like me, the first thing you do is crack open Developing Microsoft ASP.NET Server Controls and Components, thumb through to Chapter 12: Composite Controls, and read the section titled “State and Child Controls.” The gist of the section says that composite controls don't need to employ extra effort to save the view state of their children since it's saved automatically when the page recursively walks the control tree to generate the entire view state. Opening Reflector, I poured through the Page and Control classes, and saw that, yes, the control hierarchy should be walked and the view state saved, so when my composite control's SaveViewState() method was called, it should save not only its own view state, but the view state of its child(ren): namely, the DropDownList. But, evidently it was not.

This got me to scratching my head. Why isn't the DropDownList's view state being saved? EnableViewState for both the Web page, composite control, and DropDownList were all set to True (the default). I looked at the SaveViewState() method for the DropDownList and confirmed that it should be saving its view state. So why wouldn't the DropDownList be saving its view state?

And then it occurred to me - check to make sure that the DropDownList's IsTrackingViewState property is True - if it isn't, then the DropDownList won't be recording changes to its state, and therefore won't produce a ViewState. A control begins tracking its view state when its TrackViewState() method is called, and this is handled after the Initialization stage of the page lifecycle. So, if the DropDownList is being added after that stage, then it wouldn't be tracking its view state, and therefore its state would be lost on postbacks.

But wait a minute, if you add a child control via the Controls.Add() method, the added child control's TrackViewState() method is automatically called. But wait! Only those items added to the view state after the view state has started being tracked will be recorded. So binding the items to the DropDownList prior to adding the DropDownList to the Controls collection causes those additions to not be saved in the view state for the DropDownList. Rather, we need to first add the DropDownList to the Controls collection and then bind the database data to the list. The order matters because we don't want to bind the data to the DropDownList until after we've started tracking view state.

To summarize, the correct code should look like:

public class MyControl : WebControl, INamingContainer
{
...

protected override void CreateChildControls()
{
DropDownList ddl = new DropDownList();
Controls.Add(ddl); // Add the control FIRST

if (!Page.IsPostBack) // Bind data AFTER
// do data binding to some database...
}
}

Partial credit goes to (IIRC) Alex Lowe. If I'm remembering correctly, way back in (yikes!) 2001 he tech reviewed ASP.NET: Tips, Tutorials, and Code for which I authored some chapters, and on one of the chapters I had an example of adding dynamic controls to a page and - again, if my memory doesn't fail me - he noted that you wanted to first add the control to the page prior to setting properties that needed to be maintained in the view state.

Question: I set my page's EnableViewState property False; why is there still a __VIEWSTATE hidden form field?

Scott Mitchell — Fri, 23 Jul 2004 18:54:00 GMT

ANSWER: A while back I wrote an article for MSDN online titled Understanding ASP.NET View State, and blogged about the article in this past entry. I recently noticed a comment in that blog entry from Matthias Cavigelli, asking:

When I disable the ViewState property of the page, I still have the hidden field __VIEWSTATE in the html code. Could you explain why it's still there although it's not enabled?

What Matthias is referring to is the EnableViewState property, which is defined in the System.Web.UI.Control class (which means that all ASP.NET server controls have this property, including the Page class from which all ASP.NET Web pages are derived.) This property defaults to True, which means that, by default, a control should track its view state and save its view state during the SaveViewState stage of the page's lifecycle. By setting EnableViewState to false, a control is saying, "Don't bother recording my view state."

Setting EnableViewState to False on certain state-heavy controls is a good way to trim the size of a page's view state. Of course, you must take care when tweaking this property, since the state-heavy controls typically rely on the view state to maintain their functionality. Here's a good example of when you can set EnableViewState to False: when you have a DataGrid Web control on a page that simply displays data, and where the DataGrid's properties are not programmatically changed on postback. (Note: if this page does have postbacks you'll have to make sure to rebind the database data to your DataGrid on every postback.)

If your page does not perform any postbacks at all, having view state is a big waste. So, you might as well set the Page class's EnableViewState to False, so that no view state is saved for the entire page. Or so you'd think. If you set EnableViewState to False for the page, you'll still get a hidden __VIEWSTATE form field, although it will be pretty small. Why does this hidden form field exist at all?

To answer this question it is important to realize that view state really is paramount to Web Forms, not the Page class. (A Web Form is a server-side <form> tag, which is represented in the .NET Framework via the System.Web.UI.HtmlControls.HtmlForm class.) If a Web Form exists, there typically needs to be a hidden __VIEWSTATE form field. But the Web Form does not know the complete view state of the page. The Page class, for instance, has a ViewState property, into which a page developer can store items into the view state. The Web Form, obviously, is ignorant about this. So there's this chicken-and-egg thing going on here - the Page knows how to completely represent the view state, but it's the Web Form that cares about it, not the Page. The end result is that the Page class is responsible for generating the hidden __VIEWSTATE form field, but it's the Web Form that knows whether or not this is needed.

To overcome this hurdle, the Page class needs some way to know whether or not the __VIEWSTATE form field needs to be emitted or not. To allow for this, the Page class provides a public RegisterViewStateHandler() method; if this method is called during the page lifecycle, a __VIEWSTATE hidden form field will be emitted, even if the Page class's EnableViewState property is set to False.

From a Web Form's perspective, it always needs to save view state. Well, this is the way the Web Form class was programmed by Microsoft. You can see this by examining the HtmlForm class's OnInit() method:

protected override void OnInit(EventArgs e)
{
      base.OnInit(e);
      this.Page.SetForm(this);
      this.Page.RegisterViewStateHandler();
}

Personally, it would seem to make more sense to me to have Page.RegisterViewStateHandler() called only if Page.EnableViewState is true, but there may be a reason behind this that I haven't seen. Anywho, when the Web Form is rendered, it calls an additional two of the Page class's methods:

OnFormRender() - this adds the __VIEWSTATE hidden form field along with any registered hidden form fields or script blocks registered via Page.RegisterClientScriptBlock().
OnFormPostRender() - this adds any script blocks registered via Page.RegisterStartupScript() and any client-side arrays registered via Page.RegisterArrayDeclaration().

You may still be wondering why when the Page's EnableViewState is False that the __VIEWSTATE hidden form field has anything in it. Well, if you take a look at the Page class's SavePageViewState() method, you'll see:

internal void SavePageViewState()
{
      if (!this._needToPersistViewState)
      {
            return;
      }
      Triplet triplet1 = new Triplet();
      int num1 = this.GetTypeHashCode();
      triplet1.First = num1.ToString(NumberFormatInfo.InvariantInfo);
      triplet1.Third = this._registeredControlsThatRequirePostBack;
      ...
      triplet1.Second = base.SaveViewStateRecursive();
      
      this.SavePageStateToPersistenceMedium(triplet1);
}

So what you see her is the following: if _needToPersistViewState is False, then nothing is saved. Well, this flag is set to True when the Web Form calls Page.RegisterViewStateHandler(). So a Triplet is built up, with the first item containing the page's hash, the third item containing an ArrayList of Web controls that require a postback. Now, the second item is where the meat of the view state comes from - this is the sum of the view state of the controls in the page. But if EnableViewState is False for the page, SaveViewStateRecursive() returns null.

So even if you set the Page's EnableViewState to False, you'll still get a __VIEWSTATE hidden form field with the Page's hash and ArrayList of controls that require postback. I still don't see why this is needed, but there is likely a good reason.

In an upcoming article of mine for MSDN online, I talk more about the Page class's methods for registering client-side elements - scripts, arrays, hidden form fields, etc. Keep your eyes peeled on the ASP.NET Dev Center!

Largest. ViewState. Ever.

Scott Mitchell — Thu, 22 Jul 2004 12:37:00 GMT

The ASP.NET DataGrid Web control is notorious for its hefty view state size, but the DropDownList control can hold its own weight as well, especially when it contains a lot of items. For example, a page containing nothing but a DropDownList populated with ~100 items from a database will yield around 10 KB in view state. While 10 KB might not seem like much, remember that view state is a two-way penalty - it is sent down with the page's HTML and sent back during postback, thereby increasing both the download and postback time for the end user.

I just finished a page that, I think, will hold record as having the largest view state. Ever. Working on a site for a client and he needs a page that has over a dozen DropDownList controls, and each DropDownList has, believe it or not, upwards of 1,000 items. End view state? Over 800,000 bytes. In total, the page was over 2.5 MB in size. What does this mean for an average dialup user? Well, they'll have to wait nearly six minutes to download the page, and eight minutes to postback (two minutes to upload the 800 KB of view state, six minutes to download the 2.5 MB again).

Of course, I cut the view state down to a few KB by turning off view state for the page. It wasn't needed since I wasn't programmatically changing the state of the controls on the page, nor was I using the SelectedIndexChanged event of the DropDownList. But still, the page weighs in at 1.7 MB, which is still prohibitively large (even though all users are really on an intranet).

Understanding ASP.NET View State

Scott Mitchell — Thu, 03 Jun 2004 13:28:00 GMT

My latest MSDN article is now online, and covers a topic that many developers do not have as tight a grasp on as they may think. Understanding ASP.NET View State looks at how an ASP.NET page maintains its state changes across postbacks, examining:

The ASP.NET Page Life Cycle
The Role of View State
The Cost of View State
How View State is Serialized/Deserialized
Specifying Where to Store the View State Information (see how to store it in a file on the Web server rather than as a bloated hidden form field)
Programmatically Parsing the View State
View State and Security Implications

A special thanks to those who helped review this article, especially those whose feedback was used to improve the article. If you'd be interested in reviewing articles, read this blog entry for more information...

Google AdSense and ASP.NET View State

Scott Mitchell — Sat, 29 May 2004 15:43:00 GMT

I recently decided to try out Google AdSense on a few personal sites I run - ScottOnWriting.NET, NBAWebLog.com, MP3Players101.com, skmMenu.com, and DataWebControls.com - mainly as an experiment to see the effectiveness of text advertising and what sort of revenue streams small, focused sites like these are capable of generating. (I'll be sure to post an analysis after having collected sufficient data.)

The nice thing about Google AdSense is that it's a breeze to setup. Once you have an AdSense account, you just choose a few options - colors for the text ads, if you want to serve text ads only or both text and image ads, and if you want to assign the ad to a “channel” (useful for tracking performance of ads on certain sites or pages) - and, based on these selections, you're given a snippet of client-side JavaScript code to add to the page(s) where you want to display the ads. AdSense automatically scans the content of your site to send targetted text ads, and you get some money whenever anyone clicks on one of your ads. The precise amount of money you receive depends on the ads served. Essentially, advertisers can bid on showing their ads for certain keywords, so your revenue depends on how much advertisers are willing to pay for your targetted customer's clicks.

In any event, I got Google AdSense up and running on all of the sites and all of them, save one (NBAWebLog.com), displayed targetted ads. NBAWebLog.com was displaying nothing but public service ads - Save the Rainforest, Become a Big Brother, and things like that. Reading up at AdSense, I learned that these public service ads are displayed until AdSense can successfully search and categorize the site's content. After these public service ads persisted for three days, I emailed the AdSense support staff, and asked them what was up. They came back and said that their spider could not classify my site due to a large amount of non-standard content near the beginning of the page.

I visited NBAWebLog.com, did a quick view source and found... a large amount of non-standard content - several KB of base64 encoded content in the __VIEWSTATE hidden form field. This view state information didn't need to be persisted - I wasn't handling postbacks at all from the front page - so I turned off view state from the @Page directive and everything worked out. I emailed back the Google AdSense staff, got my site respidered, and now it's showing the applicable ads.

On a slight tangent, I have an article on ASP.NET view state coming up on the MSDN ASP.NET Dev Center...

A Stumper of an ASP.NET Question: SOLVED!

Scott Mitchell — Thu, 20 May 2004 19:05:00 GMT

In my last blog entry I posed an ASP.NET / Repeater question that had me and a student of mine utterly stumped. I have been communicating with this student today, bouncing ideas back and forth, and he noted that if the Repeater's EnableViewState property was set to False, then the Button column raised the ItemCommand event, as expected. Now, all that the Repeater stores in its ViewState StateBag is the number of items in the Repeater (stored in a view state variable named _!ItemCount).

Basically, when the Repeater's DataBind() method is called, the following steps happen:

The Repeater's base's Controls collection has its Clear() method called, cleaning out any controls in the Repeater's hierarchy.
The child view state is cleared out.
The CreateControlHierarchy() method is called, passing in True (indicating that the data should be bound from the DataSource).
The ChildControlsCreated property is set to True. This property is a flag to indicate that the Repeater's control hierarchy has been built. Whenever the Repeater's Controls property is accessed, it first checks to make sure that the control hierarchy has been built by calling EnsureChildControls(). EnsureChildControls() checks to see if ChildControlsCreated is false; if it is, it calls CreateChildControls().

When a Button submits a Form, the Button's name and value attributes are sent along in the POST data to the Web server. After the LoadViewState stage in the page's life-cycle (which comes before the Load stage), the ProcessPostData stage transpires. This stage loads post data back into the appropriate Web controls, such as reloading the text from a textbox back into the Text property of a TextBox Web control. Specifically, the Page class's ProcessPostData() method enumerates all the POST names passed in and searches the control hierarchy for these controls to determine if they participate in this stage of the life-cycle. In accessing the control via FindControl(), the EnsureChildControls() method is called and the Repeater's CreateChildControls() method is invoked.

Now, what does the Repeater's CreateChildControls() method do? Well, it checks to see if the view state variable _!ItemCount is null or not. If it is not null, then it calls CreateControlHierarchy(), passing in False. This builds up the control hierarchy, creating the Button. This created Button is then the Button the Page class's ProcessPostData() method marks to have its Command event raised during the RaisePostBackEvent stage later on.

Hopefully the problem is becoming clearer now. After this ProcessPostData stage, the Load stage transpires, and the Repeater's DataBind() method is called. This clears out the control hierarchy and rebuilds it. Hence, the reference to the Button we had earlier has had it's RepeaterItem “detached” from the Repeater, replaced by a new RepeaterItem isntance from the call to DataBind(). Since it's this orphaned Button's Command event that is raised, the event cannot percolate up to the Repeater, and hence the Repeater's ItemCommand event does not fire.

The LinkButton works because clicking a LinkButton does not send the LinkButton's ID through the POST data. Rather, it passes this information along in the __EVENTARG hidden form field. This information, then, is not queried by the Page class until the RaisePostBackEvents stage, which happens after the Load event, after the Repeater's control hierarchy has been constructed.

So, one workaround is as follows: don't call a data Web control's DataBind() method each and every page load if you are using view state. If you are not using view state, then you'll need to call DataBind() on each and every page load.

My student, Matt, wrote in to share the following workaround as well (I've not tested it; might not work in all browsers):

My colleague Borys has proposed a fix. I don't think I can explain it
very well, but we think it has to do with a conflict between post data
and viewstate. I'll let the code speak for itself.
Private Sub DataList1_ItemDataBound(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.DataListItemEventArgs) Handles DataList1.ItemDataBound Dim b As Button = DirectCast(e.Item.Controls(1), Button) Dim evTarget As String = b.UniqueID.Replace(":", "$") Dim script As String = "__doPostBack('" + evTarget + "','');return(false)" b.Attributes.Add("onclick", script) End Sub

Hope this helps someone, it was rather fun to examine and unearth the solution.

A Stumper of an ASP.NET Question

Scott Mitchell — Thu, 20 May 2004 15:25:00 GMT

Last night a student of mine asked why the Button Web control in a Repeater's ItemTemplate does not raise the Repeater's ItemCommand event when clicked, but a LinkButton does. I was perplexed because from my understanding anytime a Command event is raised, a CommandEventArgs is bubbled up the control hierarchy. When the RepeaterItem class detects a bubbled CommandEventArgs, it stops the bubbling of the CommandEventArgs and starts bubbling up a RepeaterCommandEventArgs instance. Likewise, the Repeater listens for bubbled events, and in detecting a bubbled RepeaterCommandEventArgs, it raises its ItemCommand event. (This is the same sequence of steps that happens in the DataList and DataGrid.)

I asked this student to show me a code sample where this was the case at a break. He did and, sure enough, the problem existed as he described. Specifically, he had a Repeater like so:

<asp:Repeater runat=“server“> <ItemTemplate> <asp:Button runat=”server” CommandName=”foo” Text=”Button” /> <asp:LinkButton runat=”server” CommandName=”bar” Text=”LinkButton” /> </ItemTemplate> </asp:Repeater>

Next, he created an event handler for the Repeater's ItemCommand event, and did a simple Response.Write() in the event handler. Finally, in the Page_Load event handler he added the code to bind the data to the Repeater on each postback. (That is, not just on the first page load...) Upon visiting the page, if the LinkButton was clicked, the ItemCommand event fired (as evidenced by the Response.Write() output, and by the debugger); clicking the Button, however, did not fire the ItemCommand event.

Clearly, this perplexed me, so I decided to spend some time researching this after class. The results I have found are very odd and run counter to my understanding of how the Repeater and ASP.NET works. I am posting this here in hopes that someone will know why this behavior exists. Let me describe my research.

I started by creating a simple ASP.NET Web page with the following HTML markup:

<asp:Repeater id="Repeater1" runat="server"> <ItemTemplate> <asp:LinkButton ID="linkButtonTest" Runat="server" OnCommand="lCommand" CommandName="bar" Text="LinkButton"></asp:LinkButton> <asp:Button OnCommand="bCommand" ID="buttonTest" Runat="server" CommandName="foo" Text="Button"></asp:Button> <br /> </ItemTemplate> </asp:Repeater>

Next I created a Page_Load event handler and BindData() method that looked like the following:

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load BindData() End Sub

Private Sub BindData()
Dim a As New ArrayList
a.Add(1) : a.Add(2) : a.Add(3)
Repeater1.DataSource = a
Repeater1.DataBind()
End Sub

Notice that the data is bound to the Repeater on each and every Page_Load. If I placed the call to BindData() in Page_Load within an If statement so that it only ran when Not Page.IsPostBack, then the problems described above did not occur.

Following these two methods, I created event handlers for the Button and LinkButton's Command event, as well as an event handler for the Repeater's ItemCommand event.

Private Sub Repeater1_ItemCommand(ByVal source As Object, ByVal e As System.Web.UI.WebControls.RepeaterCommandEventArgs) Handles Repeater1.ItemCommand Response.Write(String.Concat("<b>ItemCommand</b>: The CommandName = ", e.CommandName, "<br />")) End Sub

Protected Sub bCommand(ByVal sender As Object, ByVal e As CommandEventArgs)
Response.Write("Button Command event fired!<br />")
End Sub

Protected Sub lCommand(ByVal sender As Object, ByVal e As CommandEventArgs)
Response.Write("LinkButton Command event fired!<br />")
End Sub

Again, when running this demo the LinkButton, when clicked, would display “LinkButton Command event fired” and “ItemCommand event fired.” The Button Web control, however, would only display “Button Command event fired.” It was apparent that the Button's Command event was indeed firing, but the Repeater's ItemCommand was not. In an attempt to shed more light onto this I added code in the Command event handlers to print out the control that raised the event (the Button or LinkButton), along with its ancestors in the control hierarchy. The results stupefied me. For the LinkButton, the results were as expected:

Control Ascestors: Repeater1:_ctl1:linkButtonTest (System.Web.UI.WebControls.LinkButton) --> Repeater1:_ctl1 (System.Web.UI.WebControls.RepeaterItem) --> Repeater1 (System.Web.UI.WebControls.Repeater) --> _ctl0 (System.Web.UI.HtmlControls.HtmlForm) --> (ASP.test_aspx)

As you can see, the LinkButton was first printed, it's Parent was the RepeaterItem, it's Parent was the Repeater, it's parent was the Web Form, and it's Parent was the ASP.NET Page object. The Button results, however, were a shock:

Control Ascestors: _ctl0:buttonTest (System.Web.UI.WebControls.Button) --> _ctl0 (System.Web.UI.WebControls.RepeaterItem)

The Button's Parent, as expected, was the RepeaterItem, but the RepeaterItem has no Parent! This explained why the Repeater's ItemCommand event was not firing - the RepeaterItem could not bubble up the RepeaterCommandEventArgs up to the Repeater to raise the ItemCommand event. But why isn't there a parent for the RepeaterItem? The Button's Command event fires after Page_Load, where the control hierarchy is created (via the call to BindData(), which calls the Repeater's DataBind() method). So the RepeaterItem should indeed have a parent, namely the Repeater!

I decided to create a method to print out the entire control hierarchy. I then called this method both right after the Repeater was databound and in the Button Command event handler. The results were as expected: the entire control tree was displayed, showing that the RepeaterItem did indeed have the Repeater as its parent.

Repeater1 (Parent = _ctl0) Repeater1:_ctl0 (Parent = Repeater1) Repeater1:_ctl0:_ctl0 (Parent = Repeater1:_ctl0) Repeater1:_ctl0:linkButtonTest (Parent = Repeater1:_ctl0) Repeater1:_ctl0:_ctl1 (Parent = Repeater1:_ctl0) Repeater1:_ctl0:buttonTest (Parent = Repeater1:_ctl0) Repeater1:_ctl0:_ctl2 (Parent = Repeater1:_ctl0) Repeater1:_ctl1 (Parent = Repeater1) Repeater1:_ctl1:_ctl0 (Parent = Repeater1:_ctl1) Repeater1:_ctl1:linkButtonTest (Parent = Repeater1:_ctl1) Repeater1:_ctl1:_ctl1 (Parent = Repeater1:_ctl1) Repeater1:_ctl1:buttonTest (Parent = Repeater1:_ctl1) Repeater1:_ctl1:_ctl2 (Parent = Repeater1:_ctl1) Repeater1:_ctl2 (Parent = Repeater1) Repeater1:_ctl2:_ctl0 (Parent = Repeater1:_ctl2) Repeater1:_ctl2:linkButtonTest (Parent = Repeater1:_ctl2) Repeater1:_ctl2:_ctl1 (Parent = Repeater1:_ctl2) Repeater1:_ctl2:buttonTest (Parent = Repeater1:_ctl2) Repeater1:_ctl2:_ctl2 (Parent = Repeater1:_ctl2)

So each of the three RepeaterItems has a Parent in the Button Command event... but it seems like the Button does not have a RepeaterItem with a Parent. What in the world is happening here? And why does it work with the LinkButton but not the Button Web control? Why does it work if the Repeater's DataBind() method was not called on that page visit? Using Reflector, I've poured over the source code for the Repeater, Button, LinkButton, and Page class, but am at a loss. Does anyone have any ideas? Am I missing something simple?

My test case can be viewed online here (includes complete source code).

Thanks for any possible insight...

P.S.: If you can explain why this is happening, and if you're at Tech-Ed this year, I'll buy you a beer!! :-)

Panel Weirdness

Scott Mitchell — Wed, 28 Apr 2004 16:14:00 GMT

I recently responded to a newsgroup post on microsoft.public.dotnet.framework.aspnet.webcontrols that I thought warranted a follow-up comment here. The posters question was:

I have a Panel control containing a few TextBox controls. The Panel is originally enabled, I enter data into the TextBox controls. When I submit, the Panel is disabled during the PostBack and the TextBox controls render greyed-out, and I can see the values in the TextBox controls....this is what I expected.

I submit again, the Panel is enabled during the PostBack. All of the TextBox controls within the Panel are now enabled, however, the values are gone. This doesn't happen with a TextBox control outside of the Panel that is also enabled/disabled.

The post then contained a sample ASP.NET Web page that illustrated the problem. Namely, it had a Panel Web control with a TextBox Web control inside of it, along with a CheckBox and a Button outside of the Panel. When the page was posted back, if the CheckBox was checked the Panel's Enabled property was set to False; if the CheckBox was unchcekd, the Enabled property was set to True.

I started by testing the poster's source code in Mozilla Firefox, my default browser. When the Panel's Enabled property was set to False, the TextBox was still editable and not grayed out, nor did I lose the TextBox value when posting back after it was disabled. Doing a view source illustrated why: the Panel renders as a <table> for downlevel browsers. Setting the Enabled property to False created a table with the attribute disabled=”disabled”.

Switching to IE6, I reran the test and was able to replicate the poster's problem. IE6 renders a Panel as a <div>. When the Panel's Enabled property was set to False, the following HTML markup was generated:

<div id="panelID" disabled="disabled"> <input type="text" name="textboxID" id="textboxID" value="valueEnteredOnLastPostback" /> </div>

Note that the disabled attribute only applies to the <div>, and not the <input>. (This was the case in Firefox, too, except instead of a <div> it was a <table>.) Interestingly, with this HTML markup, IE displays the TextBoxes as grayed out - however, I could edit them! What's really interesting, though, is that when the form is submitted, IE doesn't send back the values of the TextBoxes in the HTTP POST header. I guess it hits the <div>, sees that it is disabled, and then doesn't bother processing the <div>'s inner children. (Firefox always posts back the TextBox value, regardless of the value of the enclosing <table>'s disabled attribute.) Since the TextBox value is not posted back when the Panel is disabled, the TextBox loses its Text property value, resulting in an empty TextBox on postback. The solution to this problem is to explicitly set the TextBox's Enabled property to False - not just the Panel's.

The reason the problem exists is because when a visitor enters a value into a TextBox, and posts back the form, that value is not persisted into the TextBox's view state. Yes, the value is saved to the TextBox's ViewState property, but the view state for the TextBox is only saved if the TextBox's TrackViewState property is set to True. I'm going to gloss over the sticky internal details, but realize that the TextBox does not record its Text property value in its view state if the TextBox is a Password TextBox or if there is not an event handler wired up to the TextBox's TextChanged event. If the Text property is the only property set after the Initialization stage, then the TextBox won't record any view state information. The means by which TextBox's persist their Text values across postback is by having the TextBox value continually posted back in the HTTP POST headers... but when using a disabled <div>, the TextBox value is not posted back.

An astute reader might then counter, “Well, if what you say is true, then why does explicitly setting the TextBox's Enabled property to False make everything work? After all, when the Panel is disabled, the TextBox's value is not being posted back, right?” Right you are, but when you set the Enabled property to False explicitly, that has the side-effect of setting the TextBox's TrackViewState property to True, so both the TextBox's Enabled and Text properties will be persisted to view state, and hence be used to repopulate the TextBox.

A final question readers might have is, “How in the world did you find out all this stuff?” Through the book Developing Microsoft ASP.NET Server Controls; using Reflector to look at the decompiled source code of the System.Web.UI.Control, System.Web.UI.Page, System.Web.UI.WebControls.TextBox, and System.Web.UI.WebControls.WebControl; and using a view state parser (specifically, I used one I will be presenting in an upcoming article on ASP.NET View State on MSDN, but you could use Paul Wilson's View State Parser, or Fritz Onion's ViewState Decoder).