Disable Viewstate

  • Thread starter Thread starter MCM
  • Start date Start date
M

MCM

I have the following in my web.config file (in the system.web section):

<pages enableViewState="false"></pages>

Yet, viewstate is still being included on pages. On some pages it is VERY
large. I should also mention I am using a web deployment project - not sure
if that could be ignoring the web.config file.
 
I have the following in my web.config file (in the system.web
section):

<pages enableViewState="false"></pages>

Yet, viewstate is still being included on pages. On some pages it is
VERY large. I should also mention I am using a web deployment project
- not sure if that could be ignoring the web.config file.
Click to expand...

A couple of reason I can think of off hand.

1. The web.config is in a subdirectory. This is a known issue.
2. You are using a master page that is default to true, which overrides
the setting in web.config.

I have, in the past, seen people set it up like so in either a parent
class or page, etc:

this.EnableViewState = false;

This gives more granular control. To test if viewstate is on or off,
thoughout the code, you can set a breakpoint on soemthing like:

bool testViewState = this.EnableViewState;

This can help if it is being flipped back and forth to find where it is
being set incorrectly.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************
 
The web.config is in the root directory, but some controls and pages are in
subdirs. All the pages, regardless of directory, use the same Master page. If
I disable viewstate in the master page, should that work?
 
The web.config is in the root directory, but some controls and pages
are in subdirs. All the pages, regardless of directory, use the same
Master page. If I disable viewstate in the master page, should that
work?
Click to expand...

it should. Ping back if it does not and I will see if I have some time to
play. ;-)

Peace and Grace,


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************
 
Strangely enough, it seemed to make the viewstate larger. If you have time,
I'd certainly appreciate your help. Thanks.
 
Hi,
Strangely enough, it seemed to make the viewstate larger. If you have time,
I'd certainly appreciate your help. Thanks.
Click to expand...

From your description, even if ViewState is disabled, you can still see
hidden field "__VIEWSTATE", right? Based on my experience, this behavior is
normally caused by control state, which uses the same hidden field as
ViewState to persist data by default. You can refer to the following
documentation for more details:

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

We cannot disable control state. The data stored in hidden field should be
essential data for the controls to work properly.

In a word, it's normal to still see ViewState hidden field even if
ViewState is disabled. Please check if it's caused by control state. If
not, please send me a demo project that can reproduce this issue. My email
is (e-mail address removed). Please update here after sending the project in
case I missed that email.

Regards,
Allen Chen
Microsoft Online Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 2 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions. Issues of this
nature are best handled working with a dedicated Microsoft Support Engineer
by contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
That makes sense. The more user controls I have on a page, the larger the
viewstate. So there is nothing I can do to reduce the size? It is completely
necessary?
 
That makes sense. The more user controls I have on a page, the larger
the viewstate. So there is nothing I can do to reduce the size? It is
completely necessary?
Click to expand...

I am sure this is an "it depends" type of answer. On controls, there is
the ability to turn off viewstate, but there are instances where either
a) it cannot be done or b) it should not be done.

If you are setting up a GridView, for example, and have a lot of
maniuplation, you either need ViewState or you have to come up with your
own mechanism to reconstitute the control without viewstate.

In web apps, if you are merely displaying data (a report, for example)
you can turn off viewstate completely without a lot of consequences, as
the data is view only. This is the only place I would ever recommend
large amounts of data in a form.

On the other hand, if you are actively allowing edits, you should try to
limit the data as much as possible and use viewstate to ensure you can
reconstitute the controls on the server side.

hope this helps.

Peace and Grace,


--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************
 
But is ControlState the same thing as ViewState? And if I want to turn off
ViewState in controls - do I have to do that in the @control directive on
each one? Or is there a way to do it globally in web.config?
 
But is ControlState the same thing as ViewState? And if I want to turn
off ViewState in controls - do I have to do that in the @control
directive on each one? Or is there a way to do it globally in
web.config?
Click to expand...

Not 100% equivalent. I am getting a bit confused and think I might be
missing something.

Are you embedding a lot of controls in a GridView or similar?

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************
 
Hi,
That makes sense. The more user controls I have on a page, the larger the
viewstate. So there is nothing I can do to reduce the size? It is completely
necessary?
Click to expand...

The control state is designed to persist data for controls' essential
functionality, which means if it's disabled, the control will not work
properly. So it makes no sense to disable it. But please do check if you're
using custom controls. If it's not well designed, it may abuse control
state. Since control state cannot be disabled, redundant data may be stored
in ViewState hidden field. You can view the source code of a control using
Reflector to see if it overrides LoadControlSate method and
SaveControlState() method. If it does, check what's stored in Control
State. If you don't think the data persisted is essential for this control,
control state may be abused. If you can change the control's code, you can
persist data in ViewState instead so that developers can decide whether to
disable it. If it's out of your control, please contact author of the
control to reprot this issue.

protected internal override void LoadControlState(object savedState)
{
//code
}

protected internal override object SaveControlState()
{
//code
}


Regards,
Allen Chen
Microsoft Online Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).
 
I'm not talking about pre-compiled controls. I'm talking about a simple .ascx
file that contains a few html elements and few pieces of data, and is part of
the same application project. For example, if I want to create a list of
books, I might create a book.ascx which looks like this:

<div>
<asp:Label ID="lblTitle" runat="server" />
</div>

Then in the Load code, something like:

lblTitle.Text = "Some title from the database"


Then I can reuse the control several times on the same page. What exactly
would Viewstate be doing that it is required for this control?
 
Howdy!

Whether or not something is rendered to the __viewstate field depends almost
entirely on when in the lifecycle of the control you set the values (whether
it is before or after the ViewState is being tracked) and whether or not the
ViewState item being tracked has been set to dirty or not.

TrackViewState() is called automatically when a control is initialized.
If a property that is ViewState backed is changed at anytime after
TrackViewState() has been called, it will be stored in the ViewState adds to
the length of the hidden field.
By initially setting a Labels' Text Property to String.Empty (or not setting
it), then using a Load event to set it, you are setting the ViewState
tracking of that Property to be dirty because you are changing it after the
Controls' Init Event (so it will be saved).

In order to prevent the Text values on the Label from being stored in
ViewState, use any event that takes place before or during the Labels' Init
Event to set the Text, not the Init event of the page, Load event of the
page, etc...

You can test this for yourself by putting only a Label on a page.
In the first test, set the Text property of the Label during page Load event
(or the controls' Load event), then look at the size of your __viewstate
field.
Next, set the Text property of the Label during the Labels' Init event and
then look at the size of the __viewstate field again (it'll be shorter).

If you don't have the option of changing to an earlier event, disable
ViewState at the Labels' level by setting EnableViewState="False" on the
Label controls, then, even if the Page tracks ViewState, the Label will
never set its' ViewState items to Dirty.

There are quite a few quirks surrounding ViewState management, but
understanding that something can only go into ViewState if it is set to
"IsDirty" will get you started on figuring them out.

Hope that helps!

William
 
I have User Controls (.ascx). I am using several of them on different
pages.
Click to expand...

you can alleviate some of the issue on the user control, but that is about
it. With .NET 4.0, this will change somewhat, as Microsoft gives you even
more control, but that is a topic for 2010.

Peace and Grace,

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

My vacation and childhood cancer awareness site:
http://www.crazycancertour.com

*******************************************
| Think outside the box! |
*******************************************
 
Hi,
Then I can reuse the control several times on the same page. What exactly
would Viewstate be doing that it is required for this control?
Click to expand...

Thanks for your reply. In this case, since you've specified the Text on
every postback. ViewState is not needed. You can disable them by setting

<pages enableViewState="false">

in web.config.

You can see the size of ViewState hidden field gets decreased. If you want
to know what's exactly stored in ViewState, you can use this tool:

http://www.pluralsight.com/community/media/p/51688.aspx

If your usercontrol contains some built-in controls that uses control state
to store data (for example, GridView), your page may have some data stored
in ViewState that cannot be eliminated by the <pages
enableViewState="false"> setting.

Please let me know if you have additional questions. I'll do my best to
follow up.

Regards,
Allen Chen
Microsoft Online Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).
 
I already have <pages enableViewState="false"> in my web.config. And none of
the controls have a gridview. What other things use viewstate/controlstate
other than gridview?
 
Maybe it would be easier if you would post which controls you're using.

In any case, you can disable ViewState for any control
by setting its EnableViewState property to false :

<asp:TextBox id="SomeName" runat="server" EnableViewState="false" />

Set EnableViewState="false" for all other controls on the page,
like dropdowns, buttons, etc.




Juan T. Llibre, asp.net MVP
¿ Estas probando VS 2010 y ASP.NET 4.0 ?
Regístrate (gratis) en los Foros de VS 2010 y ASP.NET 4.0, en español
http://asp.net.do/foros/forums/
=====================================================
 
Hi,
I already have <pages enableViewState="false"> in my web.config. And none of
the controls have a gridview. What other things use viewstate/controlstate
other than gridview?
Click to expand...

Thanks for your update. Almost all of the built-in ASP.NET controls uses
ViewState and some of the built-in controls such as GridView also use
ControlState. For example, the Label controls only uses ViewState to
persist data for the Text property:

public virtual string Text
{
get
{
object obj2 = this.ViewState["Text"];
if (obj2 != null)
{
return (string) obj2;
}
return string.Empty;
}
set
{
if (this.HasControls())
{
this.Controls.Clear();
}
this.ViewState["Text"] = value;
}
}

You can see ViewState is used. In addition, Label control overrides the
LoadViewState() method:

protected override void LoadViewState(object savedState)
{
if (savedState != null)
{
base.LoadViewState(savedState);
string str = (string) this.ViewState["Text"];
if (str != null)
{
this.Text = str;
}
}
}

On postback, the Text property will be reassigned so if you change Text
property on a button click event handler, the changed string will persist
for all subsequent postbacks.

If you have additional questions please feel free to ask.

Regards,
Allen Chen
Microsoft Online Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).
 
I understand how viewstate works. That is not my question.

**I already have <pages enableViewState="false"> in my web.config.**

What controls specifically (other than gridview, which I am not using) could
cause viewstate to grow?



Allen Chen said:
Hi,
I already have <pages enableViewState="false"> in my web.config. And none of
the controls have a gridview. What other things use viewstate/controlstate
other than gridview?
Click to expand...

Thanks for your update. Almost all of the built-in ASP.NET controls uses
ViewState and some of the built-in controls such as GridView also use
ControlState. For example, the Label controls only uses ViewState to
persist data for the Text property:

public virtual string Text
{
get
{
object obj2 = this.ViewState["Text"];
if (obj2 != null)
{
return (string) obj2;
}
return string.Empty;
}
set
{
if (this.HasControls())
{
this.Controls.Clear();
}
this.ViewState["Text"] = value;
}
}

You can see ViewState is used. In addition, Label control overrides the
LoadViewState() method:

protected override void LoadViewState(object savedState)
{
if (savedState != null)
{
base.LoadViewState(savedState);
string str = (string) this.ViewState["Text"];
if (str != null)
{
this.Text = str;
}
}
}

On postback, the Text property will be reassigned so if you change Text
property on a button click event handler, the changed string will persist
for all subsequent postbacks.

If you have additional questions please feel free to ask.

Regards,
Allen Chen
Microsoft Online Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).
Click to expand...
 
Back
Top