Latest Articles: ViewState

ASP.NET view state is a great feature and an essential tool for web development of today. It maintains the state of a page as it travels back and forth. There is no more need to worry about restoring values of page controls between postbacks. In this article you will get an in-depth perspective on view state. We will talk about ways of reducing unnecessary payload and protecting view state from prying eyes.

ASP .net ViewState is something that most of developers are using without even knowing that it exists, you only realize about this when you start having performance issues or your application is not working properly on a server farm (something like MD5 MAC viewstate validation failed...).

This articles explains you very basic concepts, good to start learning what in the hell is ViewState, why is not easy to get rid of it, why is useful, and where you should pay attention.

Some people think the ViewState is the spawn of the devil. Not one to be afraid of being in bed with the devil, I feel a tad bit less negative towards it, as it can be very useful.

When performance issues popups one of the first things that we developers tend to do is disable ViewState at page level... this normally reduces drammatically the size of our page.

If you are a third partie control developer... you will find that this can be a nightmare, for sure your control will need to store at least some basic information in the Viewstate. In ASP .net 2.0 you can use Controlstate to hold the minimum data to make your control to work (ControlState cannot be removed).

This article explains you how to add elements to the ControlState state in your custom control.

Microsoft® ASP.NET view state, in a nutshell, is the technique used by an ASP.NET Web page to persist changes to the state of a Web Form across postbacks. In my experiences as a trainer and consultant, view state has caused the most confusion among ASP.NET developers. When creating custom server controls or doing more advanced page techniques, not having a solid grasp of what view state is and how it works can come back to bite you. Web designers who are focused on creating low-bandwidth, streamlined pages oftentimes find themselves frustrated with view state, as well. The view state of a page is, by default, placed in a hidden form field named __VIEWSTATE. This hidden form field can easily get very large, on the order of tens of kilobytes. Not only does the __VIEWSTATE form field cause slower downloads, but, whenever the user posts back the Web page, the contents of this hidden form field must be posted back in the HTTP request, thereby lengthening the request time, as well.

Deep dive into ViewState internals

It's quite important to know how the viewstate works, in order to avoid performance issues (specially when using Partial Rendering), and... how to disable it control by control.

In this article I will discuss in detail the ASP.NET page life cycle and the ASP.NET Viewstate as an integrated unit.

Missuse of viewstate can lead you to serious performance problems... viewstate is enabled by default on every single control of your page, and removing it from your page is not something straightforward, things stop working, e.g.: controls are not correctly filled, server events does not fire...

Understand how Viewstate works is a must, and knowing how to remove it safely will save you a lot of performance problems (quite interesting... avoid using Page_Load for binding... use OnInit).

If you're a seasoned ASP.NET developer, the mere mention of view state probably sends shivers down your spine, as you envision kilobytes of base64-encoded data being sucked through a cocktail straw. Unless you take steps to prevent it, most ASP.NET pages will have a significant amount of supplemental data stored in a hidden field named __VIEWSTATE that in many cases is not even necessary. For fun, surf to your favorite sites built with ASP.NET, view the sources of the pages, and count the number of characters in the hidden __VIEWSTATE fields. I tried it and the sizes ranged from 800 to 7,800 characters.

Good info about Viewstate improvements on ASP .net 2.0, worth to read the part about control state (keep minimal info to make control to work without the ViewState).

This controlstate let us disable the ViewState and have still working server side change index events or Gridview Paging (watchout do not use DataGrid anymore :-)).

In ASP.NET pages, the view state represents the state of the page when it was last processed on the server. It's used to build a call context and retain values across two successive requests for the same page. By default, the state is persisted on the client using a hidden field added to the page and is restored on the server before the page request is processed. The view state travels back and forth with the page itself, but does not represent or contain any information that's relevant to client-side page display. In this column, I'll take a tour of the view state implementation in ASP.NET and show how to keep your Web pages fit and trim and a bit more secure.

Old but interesting article about ViewState.

You will learn a chunky way to measure the viewstate of your page (just using an alert), how to work without the viewstate and how to store it in session.

Isn't it funny how the Microsoft® .NET Framework is thought of as an environment where you don't have to think about memory? Of course, what's one of the number one issues that continues to plague managed applications today? Memory! Why? When the garbage collector runs to reclaim memory, the common language runtime (CLR) suspends all the threads in the application—and no work gets done. When you're not getting any work done, you have a performance problem.

Measuring the impact of the viewstate is not only matter of copying and pasting a hidden field chunk.

This article provides you with an httphanlder that inspects the ViewState tree telling you where are the controls that are taking a big chunk of bytes on that field.

A must read.

ViewState is a very misunderstood animal. I would like to help put an end to the madness by attempting to explain exactly how the ViewState mechanism works, from beginning to end, and from many different use cases, such as declared controls vs. dynamic controls.

Deep dive into the ASP .net Viewstate

How to disable it without breaking your code and still using it but saving a big chunk of Kilobytes

I've tried to investigate slow load of UpdatePanel. It works quick enough in FireFox, slow in IE 7 and even more slower in IE6.

A must read AJAX ASP .net trouble shooter bunch of links

How to play with compression, issues with IE6,issues with UpdatePanel, and magic web.config settings that will boost up you AJAX ASP .net application performance (compression, compilation debug, ...)

Below is the sequence of events which fire up sequentially with explanation on the relative importance with respect to web programming in code behind.

When you start developing on ASP .net you only now that you have a method called PageLoad that is you entry point for your web application, ... when you start doing thins a bit more complex: user controls, disabling viewstate on some controls... you realize that things are more complex than that.

This article tell you in which order and what is the purpose of every method called in the ASP .net page life cycle.

Microsoft’s recent announcement that ASP.NET will soon get an alternate engine in the ASP.NET Model View Controller framework (MVC-see last month’s editorial) has brought out some renewed discussion of the merits and shortcomings of Web Forms and the potential need for an alternate mechanism of building Web applications that provide a closer and purer model to raw Web development. This is true especially in light of the different development style that AJAX/Web 2.0 applications are introducing and some of the complications that it raises with the Web Forms development lifestyle.

Ms is going to release this year their implementation of the MVC pattern... this means: do not use web forms anymore, do not use updatepanel or partial rendering, do not use viewstate... do not use anything that can postback :-).

Are Web forms dead? Do Web forms sucks? What are the advantages and drawbacks?

Quite interesting topic and article.