Chapter 11: Moving to ASP.NET

This chapter is not meant to convince you to move to ASP.NET—you should already be convinced! Instead you can think of this chapter as a playbook for how you can move your current application to Microsoft .NET. You’ll note that we didn’t just say “move to ASP.NET.” When you decide to commit to ASP.NET, you’re really committing yourself to .NET. To get the most benefit from your investment, you need to think about how all the parts of your system will interact. For example, should you move your existing business logic layer (BLL) or data access layer (DAL) from COM server, written with Microsoft Visual Basic 6 or Enterprise Java Beans, to similar components written in .NET? Or should you use Web services or interop layers?

I firmly believe that before you decide to move to ASP.NET, you should first perform a full review of the technology, including writing up a plan of action for the change. You should fully understand the common language runtime (CLR) as well as the architecture of ASP.NET. Entire books are written about the CLR alone; similarly, we could dedicate an entire book to the architecture of ASP.NET—the point being that, in one chapter, we can’t possibly cover every detail you need to know to make the move to ASP.NET. However, we’ll provide a basic overview of how ASP.NET works, which will help you get started.

Web Application Architecture

Before Microsoft Active Server Pages (ASP), most dynamic Web applications were hacks; for example, my first Web applications were written on an AIX with Perl scripts. Active Server Pages 1, however, was a complete revolutionary shift in they way dynamic HTML was generated. It was one of the first technologies specifically targeted at simplifying the development of Web applications.

ASP was also one of the first technologies to successfully take advantage of the application programming interfaces, known as ISAPI, of Internet Information Services (IIS). ASP provided a high-level programming paradigm for creating Web applications. So what is ASP exactly?

Active Server Pages is a programming abstraction layer that allows developers to write interactive Web applications without requiring knowledge of low-level IIS programming interfaces such as ISAPI. ASP itself is an ISAPI extension. ASP is automatically registered with IIS.

Within IIS are two main application programming interface entry points known as ISAPI: filters and extensions. ISAPI filters participate in each request that comes into and goes out of IIS. Filters are able to filter incoming and outgoing information, adding or removing content when necessary. For example, an ISAPI filter could map incoming URLs to different paths or perform custom authentication routines, such as allowing or denying the request based on an HTTP cookie. (The best resource on ISAPI is the Microsoft Internet Information Services [IIS] 6 Resource Kit, published in 2003.)

ISAPI extensions, on the other hand, are the final target of a given request. Whereas information passes through an ISAPI filter, information is mapped to a destination by an ISAPI extension, such as a requested URL into a specific DLL (dynamic link library). For example, ASP is an ISAPI extension. Requests to IIS that end with .ASP are mapped to the asp.dll ISAPI extension.

Applications written directly in ISAPI will outperform any other type of rapid application development abstraction layer. Similarly, hand-coded x86 assembly code can outperform code written in Visual Basic 6. For example, ISAPI code that specifically loops 1000 times and writes “Hello World” would likely outperform an ASP statement that loops 1000 times and writes “Hello World.” This performance difference is due to two reasons. First, an ISAPI is composed of C++-compiled x86 instructions that are targeted directly at the processor architecture run by the platform. The ISAPI code is highly task-specific and is responsible only for the single operation of outputting HTML.

Second, an ASP consists of script code, usually Microsoft Visual Basic Script (VBScript), that must be parsed, turned into bytecode, and then executed. The script code is not compiled.

You can get the best possible performance with ISAPI, but the trade-off is the cost of development. Writing ISAPI code is not for the faint of heart. An operation that can be performed in 2–3 lines of ASP or ASP.NET code might take 20–40 lines as an ISAPI extension—and for a task as simple as writing “Hello World.” Additionally, since ISAPI is multithreaded, it requires a development language such as C++ and expertise in writing multithreaded code; Visual Basic 6 can produce only code that is apartment-model threaded or single- threaded code.

Active Server Pages Extension Mappings

The mapping of file extensions to the appropriate ISAPI extension is done within IIS. To view the extension mappings on your IIS server, open Internet Information Services. Right-click on a Web site such as Default Web Site and select Properties, which will open the Properties dialog box for your Web site. Select the Home Directory tab, shown in Figure 11-1.

Figure 11-1: Home Directory tab

Next, on the Home Directory tab, click the Configuration button. This will open the Application Configuration dialog box, which displays a table that lists the mappings of file extensions to the corresponding ISAPI .dll. This table is shown in Figure 11-2. The .ASP extension is highlighted.

Figure 11-2: File extension mappings

The two extensions, .ASA and .ASP, are mapped to the ASP.dll ISAPI extension, which are handled by ASP. The .ASA extension is a global application file in which global events are defined, such as Session_OnStart. Direct access through the browser to this file is not allowed, and this extension is mapped only to prevent unauthorized access. The .ASP extension is the main ASP extension. Files with this extension can be parsed and executed as ASP executables. Figure 11-3 diagrams what happens when IIS receives a request for the .ASP extension.

Figure 11-3: How IIS processes a request for a file with the .ASP extension

Here is a description of what Figure 11-3 illustrates:

1. A request is made to an IIS server for default.asp. IIS accepts the request and the request flows through the ISAPI filter layer first and then to the ISAPI extension layer, where it is mapped to the asp.dll extension.

2. Within the asp.dll extension, ASP first determines whether the script responsible for generating the response resides in the script engine cache. The script engine cache is a performance technique used by ASP to cache frequently accessed scripts in raw form without reparsing the ASP file. If the script code is found within a script engine cache (2b), the script code is executed (3b), and the response is generated.

3. If a script engine cache is not found for the incoming request, ASP will create a new script parser and parse the .ASP file from disk and generate the script code necessary to create the output.

4. If the requested file is being requested frequently, as we would expect with the home page, the decision to cache the generated script is made (5b).

5. The generated script is handed off to the script execution engine.

6. The generated response page, such as one in HTML, is sent back through IIS to the application that generated the request.

The ASP.NET Difference

Applications built with ASP.NET are still routed through IIS and thus must somehow interact with IIS through ISAPI. Unlike ASP, ASP.NET is written in managed code—nearly 100 percent of the ASP.NET code base is managed code written in C#. However, the interaction point between IIS and ASP.NET is still an ISAPI extension: aspnet_isapi.dll. Table 11-1 shows the extensions that are mapped within IIS to the aspnet_isapi.dll.

Table 11-1: Extensions Mapped within IIS to aspnet_asapi.dll

Entry Point	Description
.ASAX	Global application file for ASP.NET. This type of file serves a similar purpose as ASP .asa files. Global events, such as Session_OnStart, and static application variables, are declared within it. As with .ASA, direct requests for .ASAX are not allowed.
.ASCX	Extension used by ASP.NET for user controls. User controls can simply be thought of as ASP.NET pages that can be used within other ASP.NET pages as user interface–generating components.
.ASHX	Specialized extension for creating on-demand compiled ASP.NET handlers. (See Code Listing 11-1.)
.ASMX	Extension used by ASP.NET Web services to allow for SOAP-based interactions.
.ASPX	Extension used for ASP.NET pages, similar to .ASP used by ASP. It is within the .ASPX file that all user code resides.
.CONFIG	Extension used by the ASP.NET configuration system, written in XML. Rather than using the IIS metabase ASP.NET application, settings are managed within an XML configuration file.
.CS	Mapping to prevent access to C# source files.
.CSPROJ	Mapping to prevent access to Microsoft Visual Studio .NET C# projects.
.REM	Mapping used by .NET remoting.
.RESX	Mapping to prevent access to .NET resource files. Resource files contain localized strings and other resource information used by projects.
.SOAP	Mapping for .NET remoting use of SOAP.
.VB	Mapping to prevent access to Visual Basic .NET source files.
.VBPROJ	Mapping to prevent access to Visual Studio .NET and Visual Basic .NET projects.
.VSDISCO	Web service discover file. Applications can learn what Web services the server supports by querying the disco file.

Note that extensions related to ASP are not mapped to ASP.NET. This allows ASP and ASP.NET applications to run side by side without conflicting with one another. We’ll discuss this in more detail shortly.

Figure 11-4 illustrates what happens when IIS 5 receives and processes a request for the .ASPX extension. After the request is made, IIS routes the request to the ASP.NET ISAPI extension, aspnet_isapi.dll.

Figure 11-4: How IIS processes a request for a file with the .ASPX extension

Then aspnet_isapi.dll makes a named pipe call from IIS to the ASP.NET worker process: aspnet_wp.exe. This worker process hosts the common language runtime, the executing environment for .NET applications, and additionally hosts the ASP.NET HttpRuntime execution environment. The HttpRuntime is the request/response processing framework provided by ASP.NET and determines whether the requested page is already compiled. If it is, an instance of the compiled page is created, and the instance is asked to render its contents. If the page is not already compiled, the page parser attempts to load the page.

The page is located on disk and handed back to the page parser. The page parser creates a hierarchy of server control elements found within the page and emits a class file that represents the page.

The class file is given to the appropriate compiler. By default the page is compiled using the Visual Basic .NET compiler, however, you can explicitly select a compiler by specifying the language the page uses within a page directive.

The compiled class (.DLL) emitted by the page parser is stored on the disk again in a special temporary file location dedicated to ASP.NET applications (such as the location C:\WINNT\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\MyApp). At this point, an instance of the compiled page is created.

The page is asked to render its contents. Render is a special method supported by the page classes and can be thought of as the main method used by a page class. The rendered contents are then sent back through ISAPI. The generated response, such as an HTML page, is sent through IIS again and back to the application that generated the request.

In IIS 6, a dedicated IIS worker process hosts ASP.NET. No named pipe calls are made from the ISAPI extension, and the aspnet_wp.exe is not used. Rather, the common language runtime is hosted within the dedicated IIS worker process: w3wp.exe. This process is further divided into subvirtual processes known as application domains. An application domain has a 1:1 mapping to either a Web application virtual directory or a Web application root. In the application domain, an instance of the ASP.NET HttpRuntime is hosted.

HttpRuntime

The HttpRuntime models itself after the IIS ISAPI filter/extension programming model. The ASP.NET HttpRuntime is similar to the IIS ISAPI model in that it exposes two main entry points, that is, classes that implement the IHttpModule and IHttpHandler interfaces. An entry point that implements IHttpModule is similar to an ISAPI filter in that it can screen incoming and outgoing requests. A class that implements IHttpHandler is similar to an ISAPI extension. It is the target of a given extension of a request, for example, .ASPX.

The major difference between ISAPI and the ASP.NET HttpRuntime is that ISAPI filters and extensions can be written only in C++, whereas implementations of HttpRuntime’s IHttpModule and IHttpHandler can be written in any managed language, such as Visual Basic .NET. Code Listing 11-1 is a simple implementation of IHttpHandler written in Visual Basic .NET. Note that this code was written within an .ASHX file.

Code Listing 11-1: HelloWorldHttpHandler.ashx

 <%@ WebHandler Language="VB"  %>
 
imports System
imports System.Web
 
public Class HelloWorldHandler
    Implements IHttpHandler
 
    Sub ProcessRequest(context As HttpContext) 
        Implements IHttpHandler.ProcessRequest
        Dim Request As HttpRequest = context.Request
        Dim Response As HttpResponse = context.Response
 
        Response.Write("<html>")
        Response.Write("<body>")
        Response.Write("   <h1> Hello " + 
            Request.QueryString("Name") + "</h1>")
        Response.Write("</body>")
        Response.Write("</html>")
    End Sub
 
    Public ReadOnly Property IsReusable As boolean 
        Implements IHttpHandler.IsReusable
        Get
          return true
        End Get
    End Property
End Class 

Requests made to this page as HelloWorldHttpHandler.ashx?name=Rob:

Hello Rob

If you’re more intimately familiar with ISAPI, you’ll be glad to know that ASP.NET replaces the extension control block (ECB) with a much easier and friendlier managed class: HttpContext. An instance of HttpContext is created whenever a request is made to the HttpRuntime and contains all necessary information about the request and response.

Now that you’ve had an overview of how IIS, ASP, and ASP.NET work, let’s discuss some specific issues related to moving from ASP to ASP.NET.