ASP.NET 2.0 Framework | Inside Microsoft Windows Sharepoint Services Version 3

The ASP.NET Framework represents a significant productivity layer on top of IIS and the ISAPI programming model. If you are familiar with ASP.NET development, you know that it provides the convenience of writing your application logic in a managed language, such as C# or Visual Basic .NET, and working with all productivity-oriented visual designers provided by Microsoft Visual Studio. The ASP.NET Framework also provides many other valuable abstractions that assist developers in areas such as state management, data binding, navigation, and data caching.

The ASP.NET Framework is implemented as an ISAPI extension named aspnet_isapi.dll. The basic configuration for ASP.NET involves registering application maps for common ASP.NET file extensions including .aspx, .ascx, .ashx, and .asmx at the level of an IIS Web site or virtual directory. When IIS sees an incoming request targeting a file with one of these extensions, it forwards the request to aspnet_isapi.dll, which effectively passes control over to the ASP.NET Framework. The way in which the ASP.NET Framework processes a request largely depends on the extension of the target file.

The ASP.NET Framework executes the requests targeted for each IIS Web site and each virtual directory as its own independent ASP.NET application. Behind every ASP.NET application is a root directory containing a set of files. This architecture promotes a very simple x-copy style for deploying an ASP.NET application. You simply create a new virtual directory on the Web server computer and copy the ASP.NET application files into the root directory. Of course, this is a little more tedious in a Web farm environment because of the creation of a virtual directory, and the copying of the files must be duplicated over each front-end Web server in the farm.

Each ASP.NET application can be configured independently by adding a web.config file at its root directory. The web.config file is an XML-based file with configuration elements that control the behavior of various features of the ASP.NET Framework such as compilation, page rendering, and state management. A simple web.config file looks like this:

 <configuration>   <system.web>     <customErrors mode="On" />     <httpRuntime maxRequestLength="51200" />     <authentication mode="Windows" />     <identity impersonate="true" />     <authorization>       <allow users="*" />     </authorization>   </system.web> </configuration>

It is important to note that the ASP.NET Framework runs each ASP.NET application with a certain level of isolation. This is true even in a scenario when you have configured multiple ASP.NET applications to run within the same IIS application pool. The ASP.NET Framework provides isolation between ASP.NET applications running inside the same instance of the IIS worker process by loading each of them into a separate .NET Framework AppDomain.

ASP.NET Pages

The page is one of the most valuable abstractions in the ASP.NET Framework. Developers building ASP.NET applications typically construct pages by dragging and dropping server controls onto a visual design surface in Visual Studio and modifying the properties of pages and controls by using standard property sheets. The ASP.NET Framework and Visual Studio also make it relatively simple to add logic to pages by writing managed code that executes in response to page-level and control-level events.

At a physical level, a page in an ASP.NET application is a file with an .aspx extension that resides on the Web server and is compiled into a DLL on demand by the ASP.NET runtime. Consider the following .aspx page definition that contains a server-side control and a simple event handler.

 <%@ Page Language="C#" %> <script runat="server">   protected override void OnLoad(EventArgs e) {     lblDisplay.Text = "Hello, ASP.NET";   } </script> <html> <body>   <form  runat="server">     <asp:Label runat="server"  />   </form> </body> </html>

Behind the scenes, the ASP.NET Framework does quite a bit of work to compile an .aspx file into a DLL. First, it must parse the .aspx file to generate a C# (or Visual Basic .NET) source file containing a public class that inherits from the Page class that is defined within the System.Web.UI namespace inside the system.web.dll assembly. When the ASP.NET page parser generates this Page-derived class, it builds a control tree containing all of the server-side controls defined within the page file. The page parser also adds the required code to hook up any event handlers that are defined within the page.

Once the ASP.NET page parser builds the source file for an .aspx page, it can then compile it into a DLL. This compilation occurs automatically the first time the .aspx file is requested. Once the ASP.NET runtime has compiled an .aspx file into a DLL, that copy of the DLL can be used for all subsequent requests that target the same .aspx file. However, the ASP.NET runtime monitors the datetime stamp on the .aspx file and retriggers the compilation process to rebuild the DLL if it sees that the associated .aspx file has been updated.

One reason the ASP.NET Framework is so popular has to do with the convenience of server-side controls. It’s very easy to compose pages using out-of-the-box controls that ship with the ASP.NET Framework such as the validation controls, the calendar control, and controls that support data binding, such as the GridView control and the Repeater controls. Furthermore, it’s relatively simple for a developer to author custom controls and use them on pages.

Master Pages

ASP.NET 2.0 introduced master pages, which provide a very effective approach to page templating. In particular, a master page defines common elements that are to be used across many different pages (such as the top banner) as well as site navigation controls. The layout defined in a master page can then be used across many different pages that link to it. In ASP.NET terminology, a page that links to a master page is known as a content page. The basic relationship between a master page and its associated content pages is shown in Figure 2-3.

image from book
Figure 2-3: A master page defines a common layout and named placeholders that can be replaced within the content pages that link to the master page.

For example, assume that you want to create a master page that defines the HTML layout with a banner at the top of the page. You start by creating a file with a .master extension, such as default.master. Next, you add the @Master directive at the top of the page. Below that, you define the HTML layout of the page and add in named placeholders, such as the following example.

 <%@ Master %> <html> <body>   <form  runat="server">     <table width="100%">       <tr>         <td> <!-- Display Litware Banner -->           <h1>Litware Inc.</h1><hr />         </td>       </tr>       <tr>         <td> <!-- Display Main Body of Page -->           <asp:contentplaceholder  runat="server" />         </td>       </tr>     </table>   </form> </body> </html>

When you want to create a content page, you create an .aspx file and add an @Page directive that contains a MasterPageFile attribute. Once you decide which of the named placeholders from the master page you would like to replace, you then define Content elements for each one. The following is a simple example of a content page that links to the default.master page shown in the preceding code and replaces the content in the placeholder named PlaceHolderMain.

 <%@ Page Language="C#" MasterPageFile="~/default.master" %> <script runat="server">   protected override void OnLoad(EventArgs e) {     lblDisplay.Text = "Hello World";   } </script> <asp:Content  Runat="Server"              ContentPlaceHolder >   <asp:Label  runat="server" /> </asp:Content>

Note that when you create a content page that links to a master page, any HTML you would like to add must be written inside a Content element that points to a specific named placeholder. The page will not compile if you try to add HTML or server-side controls outside of a Content element. However, as you can see from the previous example, you can add a script block outside of a Content element and add whatever code you like.

When a master page defines a named placeholder, you are not required to replace it within a content page. Therefore, a master page can create a placeholder with default content inside. Any content page that links to that master page and does not include that named placeholder will get the default content. Another content page that links to the same master page and does include that named placeholder will override the default content, replacing it with its own custom content.

Finally, note that whoever creates a master page decides what the named placeholders will be and which contain default content. This is important when it comes to designing pages for a WSS site because you will be creating content pages that link to master pages created by the WSS team. In this case, you must learn what placeholders the WSS team has defined and what types of content are replaceable.

HTTP Request Pipeline

Underneath the productivity-centered architecture for pages and server-side controls, the ASP.NET Framework exposes the HTTP Request Pipeline for developers who like to work at a lower level. It provides the developer with a degree of control comparable with the ISAPI programming model. However, when you create a component for the HTTP Request Pipeline, you are able to write your code in a managed language such as C# or Visual Basic .NET. You can also use APIs provided by the ASP.NET Framework, which is much easier than using the ISAPI programming model.

Figure 2-4 displays a picture of the HTTP Request Pipeline and its three replaceable component types: HttpHandler, HttpApplication, and HttpModule. As requests come in, they are queued up and assigned to a worker thread that then processes the request by interacting with each of these component types.

image from book
Figure 2-4: The HTTP Request Pipeline allows developers to replace components such as HttpHandler, HttpApplication, and HttpModule.

The ultimate destination of any request is the endpoint, which is modeled in the HTTP Request Pipeline by using an HttpHandler class, which implements the IHttpHandler interface. As a developer, you can create a custom HttpHandler component and plug it into the HTTP Request Pipeline by adding configuration elements to the web.config file.

The HTTP Request Pipeline places an HttpApplication component in front of the HttpHandler. On an application-wide basis, incoming requests are always routed through the HttpApplication before they reach the target HttpHandler, thus giving the HttpApplication the ability to pre-process any request no matter which HttpHandler it is being routed to. This preprocessing stage is handled through a series of events that are defined inside the HttpApplication class such as BeginRequest, AuthenticateRequest, and AuthorizeRequest.

In situations when you don’t want to use a custom HttpApplication component, the ASP.NET Framework initializes the HTTP Request Pipeline with a standard HttpApplication object that provides default behavior. However, you can replace this standard component by creating a file named global.asax and placing it in the root directory of the hosting ASP.NET application. For example, you can create a global.asax that looks like the following:

 <%@ Application Language="C#" %> <script runat="server">   protected void Application_AuthenticateRequest(object sender, EventArgs e) {     // your code goes here for request authentication   }   protected void Application_AuthorizeRequest(object sender, EventArgs e) {     // your code goes here for request authorization   } </script>

The third replaceable component type in the HTTP Request Pipeline is the HttpModule. The HttpModule is similar to the HttpApplication component in that it is designed to handle events defined by the HttpApplication class and is processed before control is passed to any HttpHandler classes. For example, you can create a custom HttpModule component to handle request-level events such as BeginRequest, AuthenticateRequest, and AuthorizeRequest. As with the HttpHandler, an HttpModule class is defined with an interface. You can create a class that implements the IHttpModule interface and plug it into the HTTP Request Pipeline by adding configuration elements to the web.config file.

Whereas custom HttpApplication components can be defined as simple text files with an .asax extension, custom HttpModule components are always compiled as classes within assembly DLLs. To add a custom HttpModule component into the HTTP Request Pipeline, you then add entries into a web.config file.

While an HttpApplication component and an HttpModule component are similar in what they do, the HttpModule contains a few noteworthy differences. First, you are not limited to one HttpModule per application as you are with the HttpApplication components. The web.config file for an ASP.NET application can add in several different HttpModule components. Second, HttpModule components can be configured at the machine level. In fact, the ASP.NET Framework ships with several different HttpModule components that are automatically configured at the machine level to provide ASP.NET functionality for things such as Windows authentication, Forms authentication, and output caching.

The final component that we want to discuss with respect to the HTTP Request Pipeline is HttpContext. As ASP.NET initializes a request to send to the HTTP Request Pipeline, it creates an object from the HttpContext class and initializes it with important contextual information.

From a timing perspective, it’s important to see that ASP.NET creates this object before any custom code inside the HTTP Request Pipeline has a chance to begin execution. This means that you can always program against the HttpContext object and the child objects that it contains, such as Request, User, and Response. Whenever you are authoring a component that is to execute within the HTTP Request Pipeline, you can write code that looks like the following:

 HttpContext currentContext = HttpContext.Current; string incomingUrl = currentContext.Request.Url; string currentUser = currentContext.User.Identity.Name; currentContext.Response.Write("Hello world");

Further Reading About ASP.NET

We encourage you to learn as much as you can about ASP.NET 2.0 because it will make you a stronger WSS 3.0 developer. Many advanced ASP.NET techniques are readily available when you are creating solutions for WSS 3.0. The following list presents a few of our favorite titles.

Programming ASP.NET 2.0: Core Reference, by Dino Esposito (Microsoft Press, 2006)
Programming ASP.NET 2.0 Applications: Advanced Topics, by Dino Esposito (Microsoft Press, 2006)
Essential ASP.NET 2.0, 2nd Edition, by Fritz Onion and Keith Brown (Addison-Wesley Professional, 2007)