This article first appeared in LearnMSNET.com on June 25, 2003
Many of the web developers that are currently moving to ASP.NET were previously ASP developers, which made them used to developing their script code inline with the HTML.
This coding style of using inline code is still available within the ASP.NET framework, but a new coding style designed for large team development has also been introduced with ASP.NET this has been dubbed code-behind.
This coding style places all the code that is to be executed by the server into separate files for each .aspx page. This allows web designers who specialize in the HTML development of a site, and application developers who specialize in the programming logic of the site to work together in a way that the page designer does not disturb the code in the page. This also allows a company who is interested in protecting it’s investment or who are developing web applications for resale to distribute just the .aspx files and the compiled code-behind files as a .dll file for the site.
There are three ways of working with .aspx pages.
- Inline code that is compiled on the web server as it is needed.
- Code-behind files that are compiled into a .dll file and then removed from production.
- Code-behind files that are compiled on the web server as they are needed.
With these options in mind it becomes very important to consider how a developer will work with .aspx pages in ASP.NET. Along with the tools that will be used to develop these pages. Currently the most popular way of developing is with either Web Matrix which is available from http://www.asp.net/ or to use Visual Studio 2008. Not to say there aren’t other tools out there to develop .aspx pages because there are.
Lets look at an inline code page created by Web Matrix:
1: <%@ Page Language="C#" %>
2: <script runat="server">
3:
4: // Insert page code here
5: //
6:
7: </script>
8: <html>
9: <head>
10: </head>
11: <body>
12: <form runat="server">
13: <!-- Insert content here -->
14: </form>
15: </body>
16: </html>
The first thing to notice is the @Page directive at the top of the page. It only contains one attribute which is the Language=C#. This allows the web server to know which compiler to invoke on the code being run within the page. Immediately following the directive is this block of code:
<script runat="server">
// Insert page code here
</script>
Within this block would be placed all the code that would be run on the server for any actions that were to be taken such as a button click event or to fill a form with information from a database.
Next is the Visual Studio style of Code-Behind:
1: <%@ Page language="c#" Codebehind="WebForm1.aspx.cs" AutoEventWireup="false" Inherits="HelloWorldWACS.WebForm1" %>
2: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
3: <html>
4: <head>
5: <title>WebForm1</title>
6: <meta name="GENERATOR" Content="Microsoft Visual Studio .NET 7.1">
7: <meta name="CODE_LANGUAGE" Content="C#">
8: <meta name=vs_defaultClientScript content="JavaScript">
9: <meta name=vs_targetSchema content="http://schemas.microsoft.com/intellisense/ie5">
10: </head>
11: <body MS_POSITIONING="GridLayout">
12: <form id="Form1" method="post" runat="server">
13: </form>
14: </body>
15: </html>
This is an .aspx page that uses a code-behind file that is pre-compiled before it can be accessed through a web server. Notice that this file does not contain any server script tags like the previous file we looked at, but now the @Page directive includes the Codebehind= attribute which indicates the class file that will contain the code that would be included within the server script tags on an inline code page. The Inherits= attribute gives the namespace and class that contains the code for the page. The AutoEventWireup= attribute determines if ASP.NET controls events automatically get fired back up to the server or not.
Next is the class file that is generated to work with the .aspx page we looked at previously:
1: using System;
2: using System.Collections;
3: using System.ComponentModel;
4: using System.Data;
5: using System.Drawing;
6: using System.Web;
7: using System.Web.SessionState;
8: using System.Web.UI;
9: using System.Web.UI.WebControls;
10: using System.Web.UI.HtmlControls;
11:
12: namespace HelloWorldWACS
13: {
14: /// <summary>
15: /// Summary description for WebForm1.
16: /// </summary>
17: public class WebForm1 : System.Web.UI.Page
18: {
19: private void Page_Load(object sender, System.EventArgs e)
20: {
21: // Put user code to initialize the page here
22: }
23:
24: #region Web Form Designer generated code
25: override protected void OnInit(EventArgs e)
26: {
27: //
28: // CODEGEN: This call is required by the ASP.NET Web Form Designer.
29: //
30: InitializeComponent();
31: base.OnInit(e);
32: }
33:
34: /// <summary>
35: /// Required method for Designer support - do not modify
36: /// the contents of this method with the code editor.
37: /// </summary>
38: private void InitializeComponent()
39: {
40: this.Load += new System.EventHandler(this.Page_Load);
41: }
42: #endregion
43: }
44: }
45:
I’m not going to do much explanation of what is included in the class file for now other to note that this code behind automatically wires up a method which gets executed when the page first loads.
Next we will look at the last way of creating an .aspx page:
1: <%@ Page language="c#" Src="WebForm2.aspx.cs" Inherits="HelloWorldWACS.WebForm2"%>
2: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
3: <html>
4: <head>
5: <title>WebForm2</title>
6: </head>
7: <body>
8: <form method="post" runat="server">
9: </form>
10: </body>
11: </html>
This page still uses a code-behind file but now the file is dynamically compiled “on the fly” when the page is requested. This @Page directive contains a Src= attribute which directs the compiler to the code file to compile. The Inherits= attribute determines the class to use after the file is compiled.
In conclusion, there are many options in how to create and work with .aspx files within the .NET Framework depending on the environment that the files will be used in. If it is simply a sole developer creating the files or whether working in a huge team project that may be shipped as protected dll.