A Web Forms page consists of two parts: visual elements (HTML, server controls, and static text) and the page's programming logic. Visual Studio stores each of these components in a separate file. The visual elements are created in an .aspx, and the code is in a separate class file, called the code-behind class file (.aspx.vb or .aspx.cs).
It is also possible to create the visual elements and code in the same file, which is sometimes called a "single-file" Web Forms page. This style of Web Forms page has limited support in Visual Studio. For details, see "Single-File Web Forms Pages" below.
Note Visual Studio does not support cross-language compiling in Web Forms pages and projects. This means it is not possible to include a Visual C# Web Forms page in a Visual Basic Web project, and vice versa.
The ASP.NET Page Class
Although a Web Forms page consists of two separate files, they form a single unit when your application is run. The code-behind class files for all Web Forms in a project are compiled into the dynamic-link library (.dll) file produced by the project. The Web Forms .aspx page file is also compiled, but somewhat differently. The first time a user browses to the .aspx page, ASP.NET automatically generates a .NET class file that represents the page and compiles it to a second .dll file. The generated class for the .aspx page inherits from the code-behind class that was compiled into the project .dll file.
This single .dll file is run at the server whenever the Web Forms page is requested. At run time, this .dll file processes the incoming request and responds by dynamically creating output and sending it back to the browser or client device.
If the page contains server controls, as is typical, the derived page class acts as a container for the controls. Instances of the controls are created at run time and likewise render output for the browser or client device.
In the ASP.NET Page class model, the entire Web Forms page is, in effect, an executable program that generates output to be sent back to the browser or client device. In this model, the page goes through a series of processing stages similar to those of other components — initialize, process, and dispose — with two differences:
- The page class performs these steps each time the page is called. The page is initialized, processed, and disposed of every time a round trip to the server occurs.
- The page class has a unique stage —render— that occurs toward the end of the page life cycle, during which output is generated. For more information, see Control Execution Lifecycle.
Note For efficiency, the information required to recreate the page may be cached, but this action is independent of its life cycle.
Deriving from the Page Class
When Visual Studio creates the page and class files for a Web Forms page, it generates code that inherits from the base Page class. For example, if you create a new Web Forms page and name it WebPage1, a new class named WebPage1 is derived from System.Web.UI.Page.
Depending on whether you have chosen Visual Basic or Visual C# for your development, Visual Studio generates either of the following lines of code:
' Visual Basic
Public Class WebForm1
public class WebForm1 : System.Web.UI.Page
The .aspx page file in turn inherits from the derived WebPage1 class. The relationship of the base Page class, the derived class file, and the .aspx file is illustrated in the following diagram.
Web Forms Page Structure and the Page Base Class
Because the .aspx file is compiled dynamically when a user browses the page, its relationship to the class file is established with script directives at the top of the page. In Visual Studio, the relationship between .aspx files and class files is created and maintained automatically, even if you rename the Web Forms page. Specifically, the Inherits attribute of the @ Page directive is used to specify the class file from which the .aspx file is derived. A typical directive looks like this:
<%@ Page Language="vb" AutoEventWireup="false" Codebehind="WebForm1.aspx.vb"
The Codebehind, Inherits, and Src Attributes
In Web Forms that use code-behind files, the @ Page directive (or @ Control in user control files) contains attributes that specify the relationship of the .aspx file and its code-behind file. These attribute are:
- Codebehind In Visual Studio, this attribute references the name of a file that contains the class for the page. For example, if you create a Web Forms page in Visual Studio called
WebForm1, the Codebehind attribute will point to
WebForm1.aspx.cs. This attribute is used only by the Visual Studio Web Forms Designer. It tells the designer where to find the page class so that the designer can create an instance of it for you to work with. The attribute is not used at run time.
- Inherits Identifies the class from which the page derives. In Visual Studio, this points to a class in the project assembly (.dll), as shown in the diagram above.
The code-behind model illustrated above is the model used by Visual Studio. The ASP.NET Framework supports a slightly different code-behind model for Web Forms pages. In the ASP.NET code-behind model, the visual elements are in an .aspx file and the code is in a separate code-only file, as in Visual Studio. However, there is no project, and the code is not pre-compiled. Instead, the code in the .vb or .cs file is compiled at run time, when the page is first requested by a user.
The inheritance model works as illustrated above, with the difference that the Web Forms class (WebForm1 class in the diagram) is not part of a project assembly. Instead, each page is a separate assembly. There is no difference in how your code runs in the two models.
In the ASP.NET code-behind model, there is no Codebehind page attribute, since that attribute is unique to Visual Studio. To tie the .aspx file to its corresponding code, the page directive contains a Src attribute, which references the file containing the source code for the file.
The Src attribute is not supported in Visual Studio. If you import a Web Forms page into Visual Studio that contains the Src attribute, the designer will raise an error. For details, see The file could not be loaded into the Web Forms designer.
Single-File Web Forms Pages
In addition to pages that are made up of an .aspx file and a separate class file, the ASP.NET architecture supports a "single-file" model in which the UI elements and code are in the same file. Single-file Web Forms pages are functionally very similar to pages consisting of two files. For example, you use the same controls on both types of pages. Users still request pages using the same .aspx extension for the file name, and the page is still run using server-side code and it streams HTML to the client. A single-file page has the advantage that it can be easier to deploy.
There are a few differences in the way single-file pages are processed:
- The code for the page is not compiled into a separate class that the .aspx file then derives from. Instead, the .aspx file simply derives from the Page class.
- When the page is deployed, the source code is deployed along with the Web Forms page, since it is physically in the .aspx file. (The user does not see the code — only the results rendered when the page runs are sent to the user.)
You can work with single-file Web Forms pages in Visual Studio, but because Visual Studio is oriented toward the two-file, code-behind model, there is more limited support for single-file pages. Differences include:
- You cannot directly create a single-file Web Forms page in Visual Studio. When you create a new page, by default Visual Studio creates a separate .aspx file and class file. To create a single-file page, you must initially create it as a text file and then change its extension to .aspx.
- You cannot add non-visual components to the page (such as data components) by dragging them from the Toolbox, because the Web Forms Designer will not persist them in the page. Instead, you should add such components in code.
- You write code in HTML view, not in the Code Editor.
- When you are writing code, Intellisense is not supported — you do not get syntax checking or statement completion, tabbing, or code formatting.
- You must bind events to event handlers manually. For single-file Web Forms pages, Visual Studio does not support double-clicking to create the handler for a control's default event, nor the drop-down lists of classes and events in the Code Editor.
- Some debugging features, such as the ability to see a variable value by pointing the mouse at it, are not supported.
- Because the code in the page is not compiled into the project assembly, compile-time errors are not caught until the page runs.
For more information about single-file Web Forms pages, see Working with Single-File Web Forms Pages in Visual Studio .NET.