ASP.NET Design Goals

To understand some of the reasons why ASP.NET works the way it does, we'll cover some of the key design goals of ASP.NET in this section. We'll be looking at these in more depth later in the book. Some of the key goals of ASP.NET were to:

• Remove the dependency on script engines, enabling pages to be type safe and compiled.

• Reduce the amount of code required to develop web applications.

• Make ASP.NET well factored , allowing customers to add in their own custom functionality, and extend/replace built-in ASP.NET functionality.

• Make it easy to deploy web applications.

• Make ASP.NET a logical evolution of ASP, where existing ASP investment and therefore code can be reused with little, if any, change.

• Provide great tool support in terms of debugging and editing.

• Realize that bugs are a fact of life, so ASP.NET should be as fault tolerant as possible.

We'll examine each of these goals, and look at how they have been realized in ASP.NET.

Removal of Dependency on Script Engines

ASP prior to ASP.NET was built to take advantage of Active Scripting, a technology originally designed to enable developers to script and control applications in a uniform way. It isn't a technology that was really designed to write full-scale applications, which is essentially what many developers are trying to do using ASP. It is why ASP.NET was not written to use Active Scripting.

Active Scripting has many inherent problems:

• Code is interpreted, not compiled.

• It has a weak type system “ just variants.

• It only supports late-bound calling of methods .

• Each instance of an Active Scripting engine consumes memory.

As an ASP developer you're probably aware of these problems, and will have experienced them when developing or profiling your applications. Interpreted code results in very average performance. A weak type system makes code harder to develop, read, and debug. Late-bound code is many times slower than early-bound code, and restricts what components you can use. You may have written lots of COM components to get around these problems, but even that solution has performance and maintenance implications. Creating COM objects from ASP is relatively expensive, and upgrading COM components prior to .NET typically meant stopping your web servers.

These problems are not something that the developers of ASP.NET wanted to inherit, so the decision was made early on to use compiled code. Since the .NET platform was already in development, and had the potential to deal with the problems of COM and the Windows DNA platform in general, ASP.NET was built using C# and targeted as part of the .NET Framework.

Performance

To get great performance and remove the active scripting dependency, ASP.NET pages utilize assemblies (DLLs). The basic process is shown in Figure 2-11. When a page is first requested , ASP.NET compiles the page into an assembly. The assembly created is assigned a unique name , and is placed in a sub-directory within the %systemroot%/Microsoft.NET/Framework/[ version ]/Temporary ASP.NET Files directory. The assembly contains a single generated class that derives from the System.Web.UI.Page class. It contains all the code needed to generate the page, and is instantiated by the framework to process a request each time the .aspx page is requested.

Figure 2-11:

The page compilation process isn't cheap, and can take a few seconds for complex pages. However, the compilation is only ever done once for each .aspx file. All subsequent requests for the page “ even after IIS has been restarted “ are satisfied by instantiating the class generated, and asking it to render the page. This results in great performance. The only cost is a little disk space on the web servers.

Important

You can change the temporary directory location used by ASP.NET by adding a tempDirectory attribute to the compilation element in machine.config .

When a .NET class is generated for a .aspx page, the dependencies of that page “ such as the .aspx page and any include files “ form part of the compiled class. These dependencies are checked before a page is rendered, and if it's determined that any of the dependency files have changed since the page was compiled, the assembly is deleted and a new one is created. This ensures that the page rendered is always up to date.

The code generation and compilation classes and methods used by ASP.NET are a standard part of the .NET Framework, located within the System.CodeDOM namespace contained in the System.DLL assembly.

An Evolution of ASP

ASP.NET has been designed to maintain a general syntax and runtime compatibility with existing ASP pages wherever possible. The motivation behind this is to allow existing ASP pages to be initially migrated to ASP.NET by simply renaming the file to have a .aspx extension. Although for the most part this goal has been achieved, there are generally several basic code changes that have to be made since VBScript is no longer supported and the VB language itself has changed.

For example, you probably want to take advantage of the new architecture, viewstate, and event handling features of ASP.NET to get best performance. You may also want to use ASP.NET server controls to get better interactivity or appearance, or to generally simplify your code. In fact, in many cases, it often turns out to be easier to rewrite your pages rather than to try and update them.

However, once you have updated the pages and renamed them to have a .aspx extension, they become ASP.NET pages. Then you'll need to go through the process of fixing any errors so that those pages will be compiled, and can execute without problems. However, ASP.NET pages cannot share any type of state with ASP pages, so you cannot share information using any of the intrinsic objects, such as Application or Session . This means, for most applications, you'll typically have to convert all of your ASP pages at once, or convert groups of pages, so that they can work effectively together.

Important

You can run ASP.NET and ASP side-by-side on the same box. You can also run different versions of ASP.NET side-by-side on the same box. Version 1.1 of ASP.NET is almost completely backwards compatible with version 1.0 (see Appendix C for more details), so you can also “ in most cases “ run your ASP.NET 1.0 applications under ASP.NET 1.1.

Easy to Deploy

Deploying an ASP application onto a production web server could be a traumatic experience, especially if the application consisted of COM components and required configuration changes to the IIS meta- data. The scope of these problems would get a lot worse in a web farm scenario. You would have to copy the ASP files onto every server, copy and register the COM components, create COM+ applications and register the associated COM+ components, and update the IIS meta-data using ADSI according to configuration requirements. This installation wasn't an easy thing to do, and typically a skilled administrator might have been needed in addition to a lot of time and patience. Or you would have to write a fairly advanced setup program, which is the approach I've favored in the past.

The deployment of an ASP.NET application is radically simpler. Installing an application requires two steps:

1. Create a web site or virtual directory.

2. XCOPY application files into the directory.

Deleting an application is equally simple:

1. Delete or stop the web site or virtual directory.

2. Delete the files.

ASP.NET achieves this goal by making a few fundamental changes to the way web applications are developed:

• Configuration of applications is achieved using XML configuration files stored in the web application directories. This replaces the need to use the IIS meta-data. Also, it enables you to store your own configuration details in these files, rather than a database, which simplifies deployment. IIS 6.0 also uses an XML-based configuration persistence and backup model.

• ASP.NET ( specifically the CLR) does not require components to be registered. As long as your component files are located within the bin subfolder (you can not change the name of this directory) within your virtual directory, your ASP.NET pages can create and use components within those files.

• ASP.NET is built using the services of the CLR rather than COM. This means you can copy updated DLLs into your application directory (the bin subfolder), and it will automatically start using the components within those files, unloading the previous versions from memory.

To make redeployment of an existing application simple, ASP.NET uses the CLR shadow-copy feature to ensure component files are never locked. This means that at any point in time you can upgrade components by simply copying newer component files over the old ones. The shadow-copy feature copies the component file into a cache area before it is loaded. Thus, the original file is never actually loaded from the original location.

The shadow-copy feature of the CLR works on an application domain basis. Files are shadow- copied for each application domain. To reload a component once it's changed, ASP.NET creates a new application domain, thus causing the changed file to be cached and used. However, it only works for ASP.NET component files located in the bin subfolder.

Great Tool Support

ASP has always been a great technology for developing web applications, but it has never had great tool support, which has made web application development less productive than it really could be.

For most people in the world of ASP, Notepad was their editor, and Response.Write was the preferred and “ for the most part “ the only reliable debugging method. To be fair, Visual Interdev wasn't a bad editor, and when it worked the debugging support was pretty good (if the sun was shining and REM was playing on the radio). However, having worked on a couple of development teams where a few people were using Visual InterDev, I can quite honestly say it always seems to cause the most grief to developers (although SourceSafe is a close second). I personally never liked Visual Interdev, since debugging from ASP pages through to COM components and back again was never supported well.

Visual Studio .NET has first class support for ASP.NET page development and debugging. When developing pages, you get the same type of designer mode as Visual Interdev, but the whole layout of the Visual Studio .NET designer is much more natural and flexible. Developing an ASP.NET page is pretty much the same as developing a VB form, and very productive.

There are other tools around as well, from third-party manufacturers and the excellent (and free!) Web Matrix tool that was built by the ASP.NET team to provide a lightweight and fully functional IDE that doesn't demand the use of the code-behind approach (see http://www.asp.net/ for more details).

Debugging support in ASP.NET is also excellent. You can debug from ASP.NET pages, into a .NET component, back into ASP.NET pages with great ease. Since all of the compiled code uses the CLR to execute, the orchestration between code and Visual Studio .NET is smooth and reliable, even if you debug across multiple languages. Never again will you have to use Response.Write or a script debugger. As if this isn't enough, ASP.NET also provides excellent tracing services, which are covered in more detail in Chapter 22.

Simpler, More Flexible Configuration

The XML-based configuration model of ASP.NET makes deployment of applications much easier. The configuration is kept in text files stored with the application, so deployment is a non-issue. Furthermore, ASP.NET provides a very powerful and flexible configuration system, which is easy to utilize within your own ASP.NET pages and components.

Configuration files in ASP.NET are hierarchical “ settings defined in one directory can be overridden by settings defined in a sub-directory. A base configuration for all ASP.NET applications (machine-level) is defined in the machine.config file located with the ASP.NET system directory. This file defines global settings and mappings that are common to most applications, which include settings for:

• The time before a web request is timed out.

• Specifying the .NET classes that should be responsible for compiling and handling files of a specific extension.

• The frequency with which ASP.NET should automatically recycle its worker processes.

• The security settings that should be used by default.

A simple XML configuration file is shown here:

  <configuration>   <!-- store the database connection info here -->   <appSettings>   <add key="DSN"   value="server=localhost;uid=sa;pwd=;database=Northwind" />   </appSettings>   </configuration>  

To access and use this configuration file, you could write the following simple ASP.NET page using Visual Basic .NET:

  <%@Page Language="VB" %>   <h3>Simple Configuration Example</h3>   <%   Response.Write( "The DSN is " & ConfigurationSettings.AppSettings("DSN") )   %>  

Or using C#:

  <%@Page Language="C#" %>   <h3>Simple Configuration Example1</h3>   <%   Response.Write( "The DSN is " + ConfigurationSettings.AppSettings["DSN"] );   %>  

If you run either of these pages you'll see that the DSN is displayed as shown in Figure 2-12:

Figure 2-12:

Once loaded by ASP.NET, configuration files are cached for quick access, and so performance is excellent. The files are automatically reloaded if they are changed, so configuration updates do not require the web site to be restarted. The ASP.NET configuration system is discussed in more detail in Chapter 13.

Factored Open Design

Like ASP, ASP.NET is in part implemented as an Internet Server Application Programming Interface (ISAPI) extension DLL. ISAPI is an arcane C API that defines a standard for having web requests processed by a DLL, rather than an EXE (as happens with CGI). The benefit of ISAPI is that DLLs are far more efficient, because executables are very expensive to create and destroy for each Web request.

IIS maps ISAPI extension DLLs to web requests by matching the extension of the URI requested to a specific DLL. These mappings are defined using the Application Configuration dialog, as shown in Figure 2-13. To display this dialog, bring up the context menu for a Web site or virtual directory, and click the Configuration button on the Home Directory or Virtual Directory tab. To view or change the path to the ISAPI extension in use for a specific file type, select it and click the Edit button:

Figure 2-13:

The .aspx extension is highlighted in Figure 2.13. It shows that the aspnet_isapi.dll located in the .NET system directory is responsible for processing this request. ASP implemented a lot of functionality via its ISAPI extension DLL. It:

• Provided state management for web clients via the Session object.

• Enabled you to share data across web applications via the Application object.

• Integrated with MTS.

• Provided basic security services to protect ASP files, and helped to identify users using the security support in IIS and Windows.

This is great if you're developing an ASP application. Wouldn't it be nicer if you could use some of this functionality directly from your own ISAPI extensions, or directly from COM components, without the need to have any interpreted ASP files? And wouldn't it have been nice to be able to easily replace or enhance the functionality ASP provides; for example, moving all ASP state into a database? With ASP.NET you can easily do this.

The designers of ASP.NET realized a couple of important points early on in the design phase:

• ASP.NET should provide an extensibility model that allows services like state management to be extended or replaced with custom alternative implementations .

• A lot of the services provided by ASP, such as state management, should be usable in non- ASP.NET Web applications. The services that ASP.NET requires are common requirements for all Web application types.

• ASP.NET should not require IIS to run. It should be possible to host ASP.NET on other web servers, such as Apache.

The HTTP Runtime

To achieve these goals, the HTTP runtime was created, on which ASP.NET was built. The HTTP runtime effectively provides the same base services as ISAPI extensions and ISAPI filters (filters can preprocess requests, modify them, and so on), but it's a much cleaner model. It is built using the CLR, and has a simple object-oriented approach to managing web requests:

• A web request is processed by an HTTP request handler class.

• Services (such as the state services) are exposed to the runtime using HTTP module classes.

• An HTTP application class manages the web execution process, effectively controlling which.

HTTP modules are invoked when passing a request to an HTTP request handler, and sending the output of the HTTP request handler back to the client.

The basic structure of the HTTP runtime looks something like that shown in Figure 2-14. The number of HTTP modules is not limited, and they can be defined at a directory-level by using XML configuration files. This means that different services can be made available, and consumed by different ASP.NET pages (or any type of HTTP request handler). It enables root-level configuration defined in the .NET system directory to be redefined or removed at the directory-level.

Figure 2-14:

For example, the web.config file or machine.config in the .NET system directory may define that a specific HTTP module is loaded for state management by default. However, an additional web.config file in the same folder as a requested page (or in a parent folder of the requested page) can override this, potentially replacing the state module with another one.

All in all, the HTTP runtime is very powerful, and a lot of the functionality and power of ASP.NET (except the server-side control architecture) comes from the HTTP runtime. You can easily extend this and use it within your applications.

Web.Config for HTTP Handlers

ASP.NET is implemented as an HTTP handler. If you look at the machine.config file in the .NET system CONFIG folder, you'll see a section called httpHandlers :

  <httpHandlers> <add verb="*" path="*.aspx" type="System.Web.UI.PageHandlerFactory"/> <add verb="*" path="*.asmx"    type="System.Web.Services.Protocols.WebServiceHandlerFactory,          System.Web.Services, Version=1.0.5000.0, Culture=neutral,          PublicKeyToken=b03f5f7f11d50a3a" validate="false"/> </httpHandlers>  

This cut-down version of the section shows that all web requests with a .aspx extension are handled by the System.Web.UI.PageHandlerFactory class, and that all requests with a .asmx extension are handled by System.Web.Services.Protocols.WebServiceHandlerFactory .

To implement your own HTTP runtime handler, you can create a class that supports the HTTP runtime interfaces, add your extension and class to the web.config file, and hence write your own web technologies.

Note

When your HTTP runtime handler is hosted in IIS, you must add your extension to the IIS configuration map. Your extension should be pointed to by aspnet_isapi.dll .

Language Is Irrelevant (Almost)

When developing ASP.NET pages, the language you use is down to personal preference. Whether you use VB, C#, or even JScript .NET, you have exactly the same functionality available to you. There are no limitations or penalties imposed by ASP.NET for using a specific language.

ASP.NET uses the compilers section of the machine.config file to define the mapping of a page's extension, and available languages that can be used in ASP.NET:

  <compilers>   <compiler language="c#;cs;csharp" extension=".cs"   type="Microsoft.CSharp.CSharpCodeProvider,   System, Version=1.0.3300.0, Culture=neutral,   PublicKeyToken=b77a5c561934e089" warningLevel="1"/>   <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb"   type="Microsoft.VisualBasic.VBCodeProvider, System,   Version=1.0.3300.0, Culture=neutral,   PublicKeyToken=b77a5c561934e089"/>   <compiler language="js;jscript;javascript" extension=".js"   type="Microsoft.JScript.JScriptCodeProvider, Microsoft.JScript,   Version=7.0.3300.0, Culture=neutral,   PublicKeyToken=b03f5f7f11d50a3a"/>   </compilers>  

The compiler element has the following attributes:

• language :The abbreviations that can be specified by an ASP.NET page developer when using the language attribute, either as part of the <script> block, or as part of the page directive.

• extension :The file extension associated with the language. When a file is included as part of an ASP.NET page using one of the page directives or attributes like assembly or code behind, the extension gives ASP.NET the hint it needs to tell it how to compile the file.

• type :The fully qualified name of the code generator class, and the name of the assembly in which the class is located. A comma separates these two values.

For third-party languages, such as COBOL or Perl, to be usable within an ASP.NET page, the compiler vendors must provide a code generator class for their language that derives from System.CodeDOM.CodeGenerator , and it must be registered in this configuration section, so that ASP.NET knows how to make use of it.

Less Code, Cleaner Code, More Maintainability

One of the biggest problems with ASP was the amount of code that had to be written. To display data from a database, you had to write the code that connects to the database, and use Response.Write to output the HTML required for the table. To display a calendar, you had to write the code to create the calendar. With ASP.NET, you don't have to write code to do everything. ASP.NET server controls provide a way of declaratively building pages by using nothing but tags and attributes. These server controls encapsulate the behavior used to render the UI and respond to postback.

ASP.NET also enables you to build the following types of server controls:

• Custom server controls :You can write the server controls in a compiled form, where you develop a class that inherits from one of the ASP.NET server control classes.

• User controls :You can declare other ASP.NET pages as controls, and then use those pages to build up other pages.

Both of these approaches are shown in Chapter 18.

The ASP.NET server controls provide a great mechanism for reusing code within ASP.NET applications. Microsoft predicts that many third-party vendors will create ASP.NET server controls, and Microsoft also intends to provide more and more controls with each release of ASP.NET.

Rich Authentication Model

ASP.NET was designed to provide a rich authentication model to suit modern e-commerce application requirements. The three core modes of security supported are:

• Windows authentication :Targeted mainly at intranets , where domain accounts can be used to identify users.

• Forms authentication :Cookie-based authentication as used by sites such as Amazon.

• Microsoft Passport authentication :Cookie-based authentication performed by Passport Manager, used by sites such as Hotmail.

ASP.NET also enables different authentication models to be used within the same application. This scenario allows a single web site to be used for Intranet and Extranet purposes. The authentication models of ASP.NET are discussed in detail in Chapter 14.

Realize That Bugs Are a Fact of Life

The designers of ASP.NET appreciated from day one that nobody writes bug-free code “ including Microsoft. For this reason ASP.NET deals with bugs, expecting them to happen, and has a number of cool features:

• It detects memory leaks and automatically restarts ASP.NET applications. You define the scope of a memory leak.

• It detects hung or deadlocked requests, and resolves them.

• It automatically restarts an ASP.NET application after a specified number of requests.

• It allows state to be stored externally to the main ASP.NET worker process, even in a state service or a SQL Server database. This allows ASP.NET applications to be restarted without end users losing their state.