In this lesson, we will cover an important ASP.NET concept, and that is managing state with ViewState. Consider how the Internet, or more specifically, the World Wide Web is intrinsically a stateless environment. This means that whenever you make a page request to a web server, it processes the request and sends the result as processed HTML. At which point, nothing is being held in memory on the server in question that points to your request instance, or the values that you’ve entered. Without using a framework, like ASP.NET or PHP, all of the information in the page and in its controls will be lost with each round-trip to the server.

To overcome this intrinsic limitation of web development, the ASP.NET page framework includes several different ways to maintain state across multiple PostBacks to the web server. ViewState is one such way that allows you to preserve variable and Control values between round trips to the web server.

Step 1: Create a New Project

To illustrate this, create a new ASP.NET project called “CS-ASP_020” and create the following Controls and programmatic IDs:

  1. valueTextBox

  2. Text1

  3. addButton

  4. resultLabel


Bear in mind that the user-input box for (2) is not a TextBox Server Control, but rather an HTML Input field fond in the Toolbox:


Step 2: HTML Fields Lose Information on PostBack by Default

Run the application and input some text for both input fields and then click “Add.” You will notice that only the Server Control input field will retain the value entered, whereas the HTML input field does not. The reason for this is because the Server Control, being an ASP.NET construct, attempts to produce the appearance of a consistently held state. It’s operating under the presumption that, despite the fact that HTML is stateless, many applications end up with some form of state-mimicking behavior (to make the user-experience more fluid, for example):


Step 3: ViewState Holds Values in an Encoded HTML String

ASP.NET is able to retain this information, between server requests, by storing it in a hidden HTML form field encoded with base64 encryption. You can see this by right-clicking in a blank area of the web page in the browser and selecting the browser option to “View Source” code:


Here we see this hidden information (hidden from view on the web page) that holds ViewState information, along with the encoded values. Notice how the encoded string looks like gibberish. That string holds all of the relevant values from the previous post made to the server by pressing the "Add" button. And when the user posts back to the server, this information will be silently posted back as hidden form input, creating a bridge that carries important data between page refreshes. The more information needing to be stored by the encoded string – the longer the string grows. This presents its own set of problems, which has led many developers to pursue ASP.NET MVC (Model-View Controller), rather than ASP.NET Web Forms. The solution that MVC provides probably won’t make much sense without first understanding the problems and
solutions faced by using ViewState in ASP.NET Web Forms.


The concept of something holding a state is common throughout programming. In broader terms, holding state can be thought of as a particular configuration of any given object (in the real world, or in code) at any given moment. Consider how a Rubik’s Cube changes state every time its puzzle pieces are shifted. You don’t throw out one Rubik’s Cube and get a new one whenever you want to change its state, however, this is kind of how ASP.NET/HTML works when it comes to creating the perception of holding state. The hidden information encoded in the HTML post back to the server is kind of like telling the server what the Rubik’s Cube’s previous state was and to create a new one that resembles that state.

Step 4: Storing ViewState Values in a Key/Value Pair

Now, let’s add values to the View State by writing the following code in Default.aspx.cs:


Here we are setting the ViewState property by accessing its Add() method. This method then takes in two strings, one representing the (1) “key” and the other representing the (2) value it refers to (this key/value pairing is called a “Dictionary” in programming terms). The ViewState property is being set on Page_Load and is retrievable whenever you click on the “Add” button by displaying the value referenced when accessing the ViewState’s particular (3) key.



This Dictionary syntax might look a bit strange. Don’t worry too much about how it works right now. The important lesson here is demonstrating how the ViewState holds information in between posts to the server.

Now, let’s do something interesting:

  1. Initialize, at Page_Load, the ViewState[MyValue] key to hold an empty value.

  2. Once the button is clicked, create a temporary variable called value, that stores whatever ViewState[MyValue] currently holds.

  3. Take what’s currently stored in value and add to it what the user provided via valueTextBox, also adding a space after it.

  4. Replace whatever is currently in ViewState[MyValue] with
    whatever is assigned via value.

  5. After displaying through resultLabel, clear out what the user entered for valueTextBox.


Now, when running the application, enter into the Server Control TextBox the number 4 and click the button:


You will see the number displayed via the resultLabel:


Repeating this process, individually input each number in this sequence, clicking “Add” after each entry:

8, 15, 16, 23, 42

And you will see that the other entered values – previous to the last post back to the server – are retained in the ViewState[MyValue] property:


This example helps to illustrate the way that ViewState retains information between post backs to the server. While this concept isn’t direcly C# related, it is important to touch on and it is helpful for us to maintain state between post backs in the future. Make sure you understand this concept before moving on. Great job so far!

Lessons in this Course