2.10 Building Web Forms with Visual Studio .NET

All the topics discussed in this chapter are directly applicable to building Web forms with the Visual Studio .NET designer; however, there are some subtleties to the way the designer works that you should be aware of.

Figure 2-10 shows a sample ASP.NET Web application in Microsoft Visual Studio .NET. In this example, a pair of server-side controls has been added with the designer, and a handler has been associated with the Click event of the server-side button. There are two important Page attributes to notice in the generated .aspx file. First, note the Codebehind attribute, whose value is set to the source file for the code-behind. This is not equivalent to the src attribute discussed in Chapter 1, but is a tag used exclusively by Visual Studio .NET to associate source files with .aspx pages (so that they show up as connected in the Solution Explorer and so that the code-behind file can be brought up for any .aspx page by using the F7 key). ASP.NET does not recognize this attribute and ignores it altogether. For the code-behind class to be referenced by a Visual Studio .NET “created page, it must be compiled into an assembly and placed in the /bin directory of the virtual root for that application. This is exactly what Visual Studio .NET does for you. In fact, all code files within a Web application project are compiled into a single assembly, which is placed in the /bin directory of the virtual root associated with that project. The second important attribute to note is AutoEventWireup , which is set to false . This means that your page and code-behind class may not use the automatic event wire-up mechanism for Page events. Instead, you must explicitly register delegates for any events you want to handle.

Figure 2-10. Visual Studio .NET Web Form Application

To complete the picture, Listing 2-15 shows the code-behind file, WebForm1.aspx.cs , that is referenced by the .aspx page in our sample project. Note that when the designer is used to place a server-side control on a form, it takes care to place a protected data member of the appropriate type in the code-behind file. Also note that because AutoEventWireup is disabled from the .aspx page, the code-behind generated by Visual Studio .NET is careful to explicitly wire up the Load event handler of the Page class. The Init event of the Page class is used as the bootstrap to initialize all the other events by calling the helper function, InitializeComponent . Notice that the designer explicitly added an event handler for the Click event of the server-side button in the InitializeComponent implementation. In general, anytime you add a handler for a server-side event in the designer, it explicitly subscribes to that event in this method. The Init event is handled by overriding the virtual OnInit method inherited from the Page base class, which is registered as an event handler for the Init event in the Page class's constructor.

Listing 2-15 Visual Studio .NET “Generated Code-Behind File

 using System; using System.Collections; using System.ComponentModel; using System.Data; using System.Drawing; using System.Web; using System.Web.SessionState; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.HtmlControls; namespace WebFormsApp {   public class WebForm1 : Page   {     protected Button _PushMe;     protected TextBox _Name;     private void Page_Load(object sender, EventArgs e)     {      // Put user code to initialize the page here     } #region Web Form Designer generated code     override protected void OnInit(EventArgs e)     {       InitializeComponent();      base.OnInit(e);     }     private void InitializeComponent()     {       _PushMe.Click +=                  new System.EventHandler(Button1_Click);       this.Load += new System.EventHandler(this.Page_Load);     } #endregion     private void Button1_Click(object sender, EventArgs e)     {     }   } } 

There are several mistakes people often make when they begin working with Visual Studio .NET because of some of these default settings. The first mistake is to assume that the Codebehind attribute implicitly compiles the code-behind file when the page is accessed. This is not true, and the code-behind file must be explicitly compiled and then deployed to the /bin directory of the application. Another mistake is to remove the AutoEventWireup attribute (or set it to true ) without removing the explicit event wire-up in the code-behind file. Removing this attribute causes ASP.NET to automatically add an event handler for any function in the code-behind file or in the .aspx file that matches one of the hard-coded event handlers. In most cases, this will be the Page_Load method defined in the code-behind file, and the symptom will be that the Load event appears to fire twice for each Page creation. In reality, the Load event is firing only once, but there are now two handlers registered for the event.