Click here to Skip to main content
13,408,861 members (47,608 online)
Click here to Skip to main content
Add your own
alternative version


34 bookmarked
Posted 20 Sep 2003

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.


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.


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.


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.


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:


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.


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.


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.


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.


For further reading on this subject:


  • Version 1: 21-September-2003


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


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

You may also be interested in...


Comments and Discussions

AnswerFor Existing Applications..Create Custom PageStatePersiter Pin
hAshishNangla21-Nov-11 20:03
memberhAshishNangla21-Nov-11 20:03 
NewsEasiest ViewState Solution Around Pin
dingledoink27-Nov-07 13:33
memberdingledoink27-Nov-07 13:33 
This exclusive content from Richard Campbell of .Net Rocks! tells you about the easiest way to completely eliminate ViewState, without losing the benefits it brings!!

It's just under 6 minutes, but it gives you a lot of info., it's located near the bottom of this page under VIDEO, titled "InteropNY - Richard Campbell runs live load tests on the AS1000 in New York":

Dan Webster
Account Executive
Strangeloop Networks
Office: 604-638-1744 ext. 2703
Mobile: 778-835-5253

GeneralQuick viewstate fix Pin
paddyboyd9-May-06 6:41
memberpaddyboyd9-May-06 6:41 
Generalvalues getting set on postback Pin
DennisW987654321026-May-05 11:33
sussDennisW987654321026-May-05 11:33 
GeneralRe: values getting set on postback Pin
Colin Angus Mackay26-May-05 11:44
memberColin Angus Mackay26-May-05 11:44 
GeneralUseful and Informative Pin
Chris Keeble24-Sep-03 23:55
sussChris Keeble24-Sep-03 23:55 
GeneralRe: Useful and Informative Pin
Franck Quintana28-Jan-04 22:44
memberFranck Quintana28-Jan-04 22:44 
GeneralViewState Serialization Pin
Heath Stewart21-Sep-03 9:43
editorHeath Stewart21-Sep-03 9:43 

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

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

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.180221.1 | Last Updated 21 Sep 2003
Article Copyright 2003 by Colin Angus Mackay
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid