ASP.NET 4.0: more control on viewstate management

ASP.NET is a stable and mature platform for building Web applications. Personally, I can hardly imagine a revolutionary set of new and compelling features to be added to it. So what's new in ASP.NET 4.0? Beyond AJAX stuff, there are some interesting enhancements in the Web Forms area. As I see things, all changes in ASP.NET 4.0 can be catalogued under the label of "more control". You get more control over viewstate, script references, ID generation, output caching and even, but in very limited form, over HTML generated by some controls.

Let's briefly focus on the viewstate extended control. In ASP.NET, the viewstate is optional but it is enabled by default. In addition, the viewstate is not simply a way of reducing your bandwidth. It is rather functional to the implementation of the Web Forms model. So just dropping the viewstate in a new version of ASP.NET is simply out of question: either you get a new ASP.NET platform such as ASP.NET MVC or you stick to Web Forms with the viewstate on board.

However, there's a subtle aspect of the viewstate management that has been fixed in ASP.NET 4.0. I said fixed because, well, from my perspective it had to be considered a bug-by-design in previous versions.

All server controls (the Page class derives from Control) have the EnableViewState property through which you can disable the viewstate for that control. What is little known ais that the EnableViewState property is ignored for child controls. In other words, if you take the default value (true) for the page, then whatever value you assign for it to any controls in the page... it is ignored. You can have have TextBox1.EnableViewState = false but still have the text box to read/write state from the viewstate if the viewstate is enabled at the page (or container) level.

This will change in ASP.NET 4.0 thanks to the new ViewStateMode property.

This property indicates whether the viewstate for the control is enabled|disabled|inherit. You can use the ViewStateMode property to enable view state for an individual control even if view state is disabled for the page. This is the great news. Finally, you can now disable the viewstate on the page and decide which controls will have it enabled (opt-in). In earlier versions you could only do the reverse (opt-out): enable the viewstate and then decide which controls will not support it.

Published 13 June 2009 10:04 PM by despos

Filed under: ASP.NET 4.0

Comments

# ASP.NET 4.0: more control on viewstate management - .NET … said on 13 June, 2009 09:55 PM

Pingback from ASP.NET 4.0: more control on viewstate management - .NET …

# ASP.NET 4.0: more control on viewstate management - .NET … | Webmaster Tools said on 13 June, 2009 10:47 PM

Pingback from ASP.NET 4.0: more control on viewstate management - .NET … | Webmaster Tools

# ASP.NET 4.0: more control on viewstate management - .NET … « Management said on 14 June, 2009 11:14 AM

Pingback from ASP.NET 4.0: more control on viewstate management - .NET … « Management

# Michael said on 19 June, 2009 12:47 AM

Don't understand :

"In earlier versions you could only do the reverse (opt-out): enable the viewstate and then decide which controls will not support it".

Doesn't it contradict with the sentence before

"What is little known is that the EnableViewState property is ignored for child controls".

# despos said on 19 June, 2009 02:28 AM

Agreed :) The text is not particularly clear, but so it is the underlying topic ...

Today, you CAN opt-out controls but you must be aware that EnableViewState on child controls is ignored. So to disable viewstate on a textbox just setting EnableViewState on the textbox doesn't work. You must also ensure that EnableViewState is disabled on the parent--i.e., the page.

With ViewStateMode you can enable/disable viewstate on a child control simply setting the desired value on the property. Just easier and enabling a scenario like "I want the viewstate everywhere, except a few controls". In 3.5 SP1, there's just one way to achieve this: disabling the viewstate on the page and enabling the viewstate for the (many) controls that need it.

# .NET 4.0 ??? Part 1 « SharePoint – The MOSS said on 27 June, 2009 03:32 PM

Pingback from .NET 4.0 ??? Part 1 « SharePoint – The MOSS

# Senthil said on 27 June, 2009 03:32 PM

Thanks for Sharing it.

skurocks.wordpress.com/.../net-40-%e2%80%93-part-1

# supro said on 12 July, 2009 02:33 AM

This is certainly a great effort. I want to add you in my chat list. is it possible?

# Summary 13.07.2009 « Bogdan Brinzarea’s blog said on 13 July, 2009 05:05 AM

Pingback from Summary 13.07.2009 « Bogdan Brinzarea’s blog

# supro said on 13 July, 2009 05:38 AM

I have a textbox control and a button..I have the viewstate of page set to false and and for textbox set to true. Still the values gets retained. ANy reasons why this is happening?

# Chandra Sekhar said on 21 July, 2009 01:10 AM

This is really cool information. Hoping for more posts regarding the changes in Frame Work 4.0.

# Learning resources for ASP.NET 4.0 WebForms new features « Bogdan Brinzarea’s blog said on 06 August, 2009 02:54 AM

Pingback from Learning resources for ASP.NET 4.0 WebForms new features « Bogdan Brinzarea’s blog

# Dave Durose said on 09 September, 2009 03:38 PM

Thanks for the clarification. I guess I forgot that the EnableViewState property is ignored for child controls.

# don said on 29 September, 2009 11:52 AM

"What is little known ais that the EnableViewState property is ignored for child controls. In other words, if you take the default value (true) for the page, then whatever value you assign for it to any controls in the page... it is ignored."

Wanna bet?

# RichardD said on 30 September, 2009 07:55 AM

"EnableViewState on child controls is ignored. So to disable viewstate on a textbox just setting EnableViewState on the textbox doesn't work. You must also ensure that EnableViewState is disabled on the parent--i.e., the page."

"if the viewstate is enabled on the parent control, it cannot be disabled on any of its child controls" [1]

WRONG.

If you DISABLE viewstate on the parent, you cannot ENABLE it on a child control.

The documentation is quite clear on this. A quick look at the source code confirms that this is how it works. A simple test can prove that you are wrong.

The comment I posted three weeks ago has conveniently disappeared without a trace. Both the email I sent regarding the MSDN Magazine article and the email I sent via this blog have been ignored. You obviously can't handle constructive criticism.

[1] msdn.microsoft.com/.../de407d5b-fc71-4b00-a954-4ecf90e08da0

# AlainB said on 02 October, 2009 05:04 AM