Click here to Skip to main content
Click here to Skip to main content

Help! My ViewState Is Out Of Control

, 20 Sep 2003
Rate this:
Please Sign up or sign in to vote.
How to reduce the viewstate your application generates and the effects of its reduction.

Introduction

This article is about ASP.NET ViewState and how to minimize it. It discusses what it is used for in particular situations and what will be affected if it is turned off or fine tuned. This is an important topic if you write web pages that will be downloaded over a dialup connection and it may also be of interest to anyone who generally wants to reduce the bandwidth their pages take.

At the moment this article should be treated as an early version as I plan to add to it as I seem to keep discovering new things about ViewState. I also invite you to comment on other ways you've found to cut down on the amount of ViewState in a page. What did it affect? How did you re-implement the functionality that the ViewState offers?

What's not yet covered? The main topics that are not yet covered that I plan to add in the near future are Radio and Check Box lists, Data Grids and Data Lists. The sheer quantity of ViewState that a DataGrid emits sends shivers down my spine.

Background

I didn't find much good information about ViewState in ASP.NET, just the occasional reference to it. As a result some of the pages I have created in the past I had to rework because the ViewState was getting way out of control, and then I was left wondering how to re-implement the same features without using the ViewState. For something that can take a large amount of space (bytes) on a web page I felt it was an issue to be addressed. I also wanted a nice reference that I could go to when I needed to remind myself about ViewState.

Labels

So, you think a label won't store ViewState? It's static; it doesn't take input from the user. What on Earth does it need ViewState for?

A label that is defined in the designer, even although it has ViewStateEnabled=true doesn't normally have any ViewState associated with it. However, if you assign to the Text property of the Label object in code ViewState information appears as if by magic.

What's happening? Well, the ASP.NET looks to see if it needs to maintain changes between postbacks and if it finds any it will put that in the ViewState. If the EnableViewState is set to false the change of text value will not be placed in the ViewState and will revert to the value in the designer unless some code changes it again.

So how do I reduce the ViewState size? If the text will be the same for all page requests then you can put the text in at design time. If you can easily repopulate the text of the label for each page request you can save yourself some ViewState space by setting EnableViewState=false. If the text of the Label changes for each page request then there is no point saving ViewState information so, again, set EnableViewState=false.

Labels can also have tooltips. For more information see the section on Tool Tips below.

Buttons

Under most circumstances the button control will normally not need to store ViewState information because for the most part the button name is the same for every page request and this is set up in the designer (i.e. in the ASPX file and not the code-behind file). This is very much like the Label control. It doesn't look like it should need to store ViewState, but in certain situations it does. Also, like the label, it is changes in the Text property that is causing the values to be stored in the ViewState.

So how do I reduce the ViewState size? If the button caption is the same for all requests then set it in the designer. If the button caption changes and the time taken to retrieve the caption text is sufficiently fast then disable the ViewState and set it on every page request.

Buttons can also have tooltips. For more information see the section on Tool Tips below.

DropDownLists and ListBoxes

The ViewState of these controls stores all the elements of the list if you allow it. As with other controls, setting the list items in the designer will eliminate the need for ViewState information to be stored and setting the list items from code will cause ViewState to be used.

It is also worth noting that if you have EnableViewState=true and you set the Items in the code then make sure that this is only done on the first request. Subsequent requests will cause the Items collection to be populated with information from the ViewState. If you attempt to populate the list again from code on a postback, the Items collection will end up with duplicate entries and the amount of ViewState used will grow to accommodate these "new" items.

The difficulty with DropDownLists and ListBoxes is that you cannot just disable the ViewState and repopulate the list on each postback. What if the user selects something in the list? The change event won't get fired if EnableViewState=false. If you absolutely must eliminate the ViewState you will have to detect the change yourself and call the appropriate code to handle the change. You can check Request.Form collection using the control name as the key in the indexer method to find what value the user set in the control.

If you've decided that rolling-your-own change handler is too much work and want to retain the ViewState there are still ways of reducing it. If you populate a control like this:

myDDL.Items.Add(theTextString);

you could make savings if you used:

myDDL.Items.Add(new ListItem(theTextString, correspondingIDString));

if the correspondingIDString has fewer characters than theTextString. This is because, behind the scenes, ASP.NET sets the text and value components of the ListItem to the same string (if you only supply the one string) and both the text and the value is stored in the ViewState. If you are used to just setting one string when adding to the Items collection, then you will have to alter the code slightly because the SelectedValue will return the correspondingIDString. To get access the text as displayed in the control to the user use SelectedItem.Text.

CheckBox

The Text property uses ViewState in a way very like the Label or Button control does with its Text property, so I won't repeat the same things again. This control also supplies a tooltip property so see below for more information on that.

RadioButton

Again the Text and Tooltip properties acts like their counterparts in Label, Button and CheckBox, however Radio Buttons have another property that needs to be taken into consideration, the GroupName. If the GroupName is set in the designer then no ViewState is present. If the GroupName is set in the code then it will be present.

If you set the EnableViewState=false and the GroupName is set in the code-behind then the registered CheckChange event will not be fired. If you must eliminate the ViewState you will need to set up a custom handler for the event. The value of the selected radio button will be in the Reqest.Form collection with the GroupName as the key and the RadioButton.ID as the value.

Tool Tips

Even tool tips generate ViewState information. This is similar to the way the Label and Button control's generate ViewState for the Text property. Essentially, if the tool tip value is static it should be set in the designer (it won't emit ViewState if you set the value in the ASPX page). If it is dynamic and changes value on each page request or if it can be set on each page request fast enough then set EnableViewState=false and set the value on each page request.

Notes

During this article I have mentioned the differences between setting items in the ASPX file (or in the designer) and in the code-behind file. The effect is the same if the code that was in the code-behind file is move to a server-side script in the ASPX file.

References

For further reading on this subject:

History

  • Version 1: 21-September-2003

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

Share

About the Author

Colin Angus Mackay
Technical Lead
Scotland Scotland
Have been a Code Project MVP 5 years running and was Microsoft C# MVP 4 years running, MBCS, MIAP and a whole bunch of other stuff. Now I just help run Scottish Developers which is a user group with software development events in Edinburgh, Glasgow and Dundee and I have also started an open source project to help with Password Validation
 
Main topics I blog about:
* Parallelization in .NET
* Code Quality
* Data Security
Follow on   Twitter

Comments and Discussions

 
AnswerFor Existing Applications..Create Custom PageStatePersiter PinmemberhAshishNangla21-Nov-11 19:03 
NewsEasiest ViewState Solution Around Pinmemberdingledoink27-Nov-07 12:33 
GeneralQuick viewstate fix Pinmemberpaddyboyd9-May-06 5:41 
Generalvalues getting set on postback PinsussDennisW987654321026-May-05 10:33 
GeneralRe: values getting set on postback PinmemberColin Angus Mackay26-May-05 10:44 
GeneralUseful and Informative PinsussChris Keeble24-Sep-03 22:55 
GeneralRe: Useful and Informative PinmemberFranck Quintana28-Jan-04 21:44 
GeneralViewState Serialization PineditorHeath Stewart21-Sep-03 8:43 
FYI...
 
Actually, if you look at the IL (or cheat and use a decompiler), almost every property is stored in ViewState for every WebControl. EnableViewState is more about whether or not the ViewState is serialized to the page. In your Label example, you discuss what the ViewState for a label is used for. Actually, if you look at the IL, you'll see that there is no instance variable for the Text property. It is stored in the ViewState.
 
 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.21
GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++
-----END GEEK CODE BLOCK-----

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web01 | 2.8.141015.1 | Last Updated 21 Sep 2003
Article Copyright 2003 by Colin Angus Mackay
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid