2

I disabled viewstate in the web.config file (and there's no EnableViewState = true anywhere on the pages), but despite this, the pages are rendered with a quite large view state (8k for a 40k page). I checked the viewstate contents with a viewstate decoder and discovered that the multiview controls I'm using on my pages are the guilty ones. Is there anyway to make the multiview controls stop using the viewstate?

I'm thinking about creating a control class that inherits from MultiView and override the LoadViewState and SaveViewState methods but I'm leaving this as a last resort, any suggestions?

Thanks

Waleed Eissa
  • 10,283
  • 16
  • 60
  • 82

5 Answers5

4

here is a wonderful way to just get rid of viewstate from being sent over wire for each post-back. basically, it stores the complete viewstate as a session variable on the server and only transfers the identifier in the viewstate field.

compression will save you little bit in terms of bandwidth whereas putting getting viewstate out of the page will have quite dramatic performance improvement

the following articles explains several techniques with performance measurement metrics as well eggheadcafe

Vikram
  • 6,865
  • 9
  • 50
  • 61
  • Thanks for the suggestion but actually I'm trying to get rid of viewstate completely – Waleed Eissa May 22 '09 at 11:10
  • you can just stop the viewstate field being rendered completely using the method given in the article i posted. I think asp.net will always generate viewstate field even if you have disabled it, for some minimal information. – Vikram May 22 '09 at 11:33
3

Since ASP.NET 2.0 the internal content of the ViewState hidden field is made up of the "old" ViewState (the ViewState state bag / dictionary) AND the ControlState. The Control State unlike the ViewState cannot be disabled and it is intended for the minimal information that a Control needs to function properly.

You cannot disable the ControlState and you either live with it either use a different (kind) of control on your page.

Andrei Rînea
  • 20,288
  • 17
  • 117
  • 166
2

You could override the render for your page (or base page) scan for the viewstate hidden input and remove it from the writer.

steps:

  • do the base.render
  • output the htmlwriter contents to a string
  • remove input with __viewstate
  • write the new string to the HTMLWriter.
Jeff Martin
  • 10,812
  • 7
  • 48
  • 74
1

To answer my own question, I managed to get rid of the viewstate by removing the form runat="server" I had in my master page, now I only enclose the controls that really need postback in a form tag with runat=server. It seems to be discarding the control state as well (which is what I want, the page doesn't post back), will still have to investigate more though.

The only problem that's left is that when I add a form runat=server tag anywhere on the page, the Multiview finds my form tag and add its trash in the hidden viewstate field, I was thinking this would happen only if the multiview is enclosed in a form runat="server" tag but it's smart enough (or dumb enough in this regard) to find the form tag anyway.

Waleed Eissa
  • 10,283
  • 16
  • 60
  • 82
0

The System.Web.UI.Page class has a property called PageStatePersister that you can override in your pages. Here you can return a PageStatePersister type object that overrides the default persistence mode for the pages viewstate.

As Vikram suggested you can use a SessionPageStatePersister to store viewstate in session instead of a hidden field. But you can also implement your own PageStatePersister that stores the viewstate in the Cache or a database or a file. Whatever you need really.

The thing you shouldn't do is to use the PageStatePersister to discard viewstate, for the viewstate is needed by some of your controls.

Rune Grimstad
  • 35,612
  • 10
  • 61
  • 76
  • ViewState (or ControlState) is needed only if the page actually ever does a postback.... – RickNZ Dec 20 '09 at 16:19
  • Good point. In most cases you pages will do a postback I think, but if you can avoid it then you can disable the ViewState entirely. – Rune Grimstad Dec 21 '09 at 07:21