Wean Yourselves off View State From the Start

Whenever I start a new project these days, I head straight to web.config and do this:

<pages
   enableViewState="false"
   enableSessionState="false"
   autoEventWireup="false">

The key here is the first attribute. If you knock out view state right from the start, I can guarantee you will approach your site differently.

You won’t be tempted to drag and drop DataGrids, which are view state hogs because they depend on it for paging and sorting. To me, the DataGrid control is the ultimate insult to aesthetics.

You won’t be tempted to stuff junk if view state simply because it’s a seemingly convenient practice.

You won’t be tempted to use autopostback with dropdowns and such.

You will do a lot of things differently without view state. Try it.

Cannot agree more! This is your best friend if you want a quality web app.

Rock on, man!

What are the ramifications of autoEventWireup="false"?

Does that mean that void Page_Load(object sender, EventArgs e) needs to be in an overriden OnInit(EventArgs e) method?

AutoEventWireUp is used to associate OnLoad to Page_Load automatically. By default at machine.config the attribute is true. What this really means is you need to write the override code for Page_load and Page_Init ; in case it is false else it is done automatically.

Hope it Helps
Jatinder Singh

Great clarification, Jatinder.

I have a strong dislike for methods with magic names such as Page_Load. Please take a look at this article of mine. I prefer to be expressive which virtual methods I want to override. Besides, I don't want to pay the price of discovering those magic methods via reflection.

You folks mentioning autoEventWireup="false" and Page_Load: this is an area that VB is better than C#. (Not sure if the new version of C# still lacks the feature.)

In VB, you can turn off autoEventWireup and use the Handles clause on a method to wire it to the event. It has many benefits: it does not rely on "magic name" and reflection, you are not reliant upon the autoEventWireups, and it is superior in terms of clear coding techniques. (Self-documenting.)

Why disable Sessionstate?
This might seem like a stupid question... but then how do you track sessions?

So you wouldn't be tempted to abuse the session state. :) Burn that bridge.

Btw, not a stupid question at all.

Hmmm... I now feel like I'm being "upsold". I found this page whilst googling for a solution to a recently surfacing viewstate error - and am even considering turning it off to "see what happens" (I'm racking my brains to think, did I actually use viewstate anywhere??).

A world without viewstate is potentially attactive... but a world without sessions?? That's too rich for me!! :-)

LOL! This post is "three for the price of one." What was your view state error all about?

> What was your view state error all about?

I'm not sure yet... :-(

The site is kind of 'like' a banking site - is, SSL, large number of pages, users log in etc. I'm not sure if it makes a difference, but there's quite a large "data access layer" DLL behind the site that drives the business logic. Each session is 'non trivial' with regards to increased session load.

The site's been live for about 8 months, receiving between 80 - 120 visits per day. Last week, some marketing went out via an email blast, which spiked usage up to 800 visits per day. In that time, I've received two viewstate errors, similar to below.

I'm wondering if the increased load is causing the application pool to recycle (see http://support.microsoft.com/kb/555353) more frequently and hence this issue to present.

The site's running on Framework 3.5 - I have a small (but manageable) addiction to Linq!! ;-)


Error Thrown from IP 128.250.5.247.

System.Web.UI.ViewStateException: Invalid viewstate.
Client IP: 128.250.5.247
Port: 50613
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30)
ViewState: /wEWBQLU2r2ICALixKoUAtvJ3a8CAubk9ZIIAvbHi9AIStEdbkOBWg4wFYwsBjv1apx+h2s=
Referer: https://secure.....

I see. This is one very elusive error because there are sooo many things that can go wrong.

It has bitten me with dynamic controls before.

It also happened to me numerous times when visitors came through proxies which maimed the view state string.

If your site runs in a web farm, make sure the machineKey section in web.config is the same.

Etc, etc.

I'm willing to bet that your DAL has little to do with this.

Thanks Milan.

> happened to me ...when visitors came through proxies

Hmmm - I hadn't thought of that! I assume that there's nothing that can be done about it short of disabling viewstate?

Normally, I don't worry about those.

In my case, more often than not someone is trying to hack my view state string sitting behind an anonymous proxy. Even when that's not the case, there's nothing I can do about those proxies anyway.

An if view state is disabled altogether, who cares? :)

Thanks Milan.

I'm going to turn off viewstate in the dev envionment (but not sessionstate!!) and see what breaks :-)