How do I turn off viewstate for good?

Question

Coming from a PHP background I love using clean URLs to grab data from one service to another.

However, on some of my ASP.NET projects I get the horrible ViewState parameter in my URLs.

Is there a way to turn this off globally?

What affect will this have on my ASP.NET app?

Karlmarxstadt

Answer 1

You can turn off viewstate for the whole site like this:

    <system.web>
<pages enableViewState="false" />

That said, you shouldn't be getting it on the url. ViewState is a hidden field that is sent to the server with a postback (which normally uses post). It keeps the state of the controls when the page was rendered to the client, sending it with each postback. If it works for the application you could switch to use post instead (the problem form is surely using get), if not take a look at Jon's answer.

Check this link for more information on how the viewstate fits into the asp.net life cycle: http://msdn.microsoft.com/en-us/library/ms972976.aspx.

Trump

Answer 2

I had a similar question when writing the Reputation Tracker.

I don't know how you do it globally other than to just never use a form with runat="server" set, which is more to do with discipline than a setting. In particular, if you have runat="server" set on a form I believe you'll always get a viewstate parameter, even if you've turned it off everywhere so you don't get any values. That was my experience, anyway.

Obviously this limits you somewhat, but I've found that using the HTML server controls (instead of the ASP.NET controls) for appropriate parts of ASP.NET can make life a lot simpler to understand.

Lahnda

@TFD: While that certainly happens sometimes, I'm not convinced it's the case here. Using forms with runat="server" in conjunction with GET actions (instead of POST) results in exactly the kind of behaviour the questioner doesn't want. How is my answer not relevant? – Lahnda

@TFD Jon is right, you might want to check the links he posted before going public like that ;) – Trump

GET is probably inappropriate when you really want viewstate - but it's very useful when you don't need viewstate. In particular, it's a lot easier to bookmark a URL with GET parameters than sorting out posting back viewstate :) – Lahnda

Answer 3

Turn off the ViewState by default by using a <page> element in the web.config. Using EnableViewState="true" in the @Page directive will no longer work once you disable the ViewState in the web.config. If you decide later that you need the ViewState for a specific page, you can turn it back on for just that page using a <location> element.

<configuration>
  <system.web>
    <pages enableViewState="false" />
  </system.web>

  <location path="MyFolder/MyPage.aspx">
    <system.web>
      <pages enableViewState="true" />
    </system.web>
  </location>
  <location path="Site.master">
    <system.web>
      <pages enableViewState="true" />
    </system.web>
  </location>
</configuration>

You need to do the same for any master pages that your ViewState enabled page uses.

Surgeonfish

Answer 4

Add this to the web.config file:

<Pages enableViewState="false"/> 

Lewie

Answer 5

You could switch to ASP.Net MVC. From what I understand it doesn't use the ViewState.

Insurer

Answer 6

Do recall, however, that certain behaviors expected by most ASP.NET web forms developers will not work without ViewState. The purpose of ViewState is to provide the illusion that various page and control properties persist from one request to the next. ViewState does not contain all control properties, just those that have changed. The idea is that ViewState retains these properties as they were at the time the form last rendered.

One good example is a SelectedIndexChanged event on a dropdown (one that does not have autopostback set). This works because ViewState retains the previous index, and the form posts the current index, and the control compares the two in order to know that the selected index has changed. That's when it raises the SelectedIndexChanged event. Without ViewState, that event will not fire. Same for TextChanged events, etc.

Absent the GET situation (which I have never run into), the big problem with ViewState is using it where it's not needed. Your grid control does not need to retain the previous values of all controls in all its rows, so don't enable ViewState on it.

Bechler