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 p
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.
Add this to the web.config file:
<Pages enableViewState="false"/>
You could switch to ASP.Net MVC. From what I understand it doesn't use the ViewState.
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.
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.
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.