How Control Tags Are Connected to Page Variables in ASP.NET

When you request your web page in a browser, ASP.NET starts by finding the associated code file. Then, it generates a variable declaration for each server control (each element that has the runat=”server” attribute).

For example, imagine you have a text box named txtInput:

<asp:TextBox id=”txtInput” runat=”server”/>

ASP.NET generates the following member variable declaration and merges it with your page class using the magic of partial classes:

protected System.Web. UI.TextBox txtlnput;

Of course, you won’t see this declaration, because it’s part of the automatically generated code that the .NET compiler creates. But you rely on it every time you write a line of code that refers to the txtlnput object (either to read or to write a property):

txtInput.Text = “Hello.”;

To make sure this system works, you must keep both the .aspx markup file (with the control tags) and the .cs file (with the source code) synchronized. If you edit control names in one piece using another tool (such as a text editor), you’ll break the link, and your code won’t compile.

Incidentally, you’ll notice that control variables are always declared with the protected accessibility keyword. That’s because of the way ASP.NET uses inheritance in the web-page model. The following layers are at work:

1. The Page class from the .NET class library defines the basic functionality that allows a web page to host other controls, render itself to HTML, and provide access to the traditional ASP-style objects such as Request, Response, and Session.
2. Your code-behind class (for example, TestFormCodeBehind) inherits from the Page class to acquire the basic set of ASP.NET web-page functionality.
3. When you compile your class, ASP.NET merges some extra code into your class (using the magic of partial classes). This automatically generated code defines all the controls on your page as protected variables so that you can access them in your code.
4. The ASP.NET compiler creates one more class to represents the actual .aspx page. This class inherits from your custom code-behind class (with the extra bit of merged code). To name this class, ASP.NET adds _aspx to the name of the code-behind class (for example, TestFormCodeBehind_aspx). This class contains the code needed to initialize the page and its controls and spits out the final rendered HTML It’s also the class that ASP.NET instantiates when it receives the page request.

How a page class is constructed.

So, why are all the control variables and methods declared as protected? It’s because of the way inheritance is used in this series of layers. Protected variables act like private variables, with a key difference - they are accessible to derived classes. In other words, using protected variables in your code-behind class (for example, TestformCodeBehind) ensures that the variables are accessible in the derived page class (TestFormCodeBehind_aspx). This allows ASP.NET to match your control variables to the control tags and attach event handlers at runtime.