During the past several years, Microsoft's Active Server Pages (ASP) Web-development technology has become one of the most-used tools for developing dynamic, data-driven Web applications. Now, Microsoft has introduced ASP.NET, a successor to ASP that dramatically improves on ASP's performance, reliability, and speed of development. Just how different is the new ASP.NET Web-development technology from the ASP that developers know and (mostly) love? In terms of migrating existing pages, ASP.NET isn't all that different, and much of your current ASP code will run fine under ASP.NET. You can also run ASP pages side by side with ASP.NET applications (although ASP and ASP.NET applications don't share application or session states), so you don't have to migrate all at once. But at its heart, ASP.NET is as different from ASP as a Hemi 'Cuda is from a VW Beetle. Both of them can get you where you need to go, but one is vastly more powerful than the other and gives you more options for customization. Part of that power comes from ASP.NET's tight integration with Microsoft's next-generation data-access technology, ADO.NET, which gives you robust and high-performance data binding.

What else makes ASP.NET so much more powerful than ASP? For starters, it's built on Microsoft's new .NET platform, a set of technologies that provides a modernized, language-independent replacement for the Win32 APIs. Some characteristics of ASP.NET are

  • use of fully compiled, instead of interpreted, languages
  • simplified programming model similar to that of Visual Basic (VB)
  • a wealth of built-in functionality in the .NET Framework Class Library
  • improved performance and scalability, manageability, code separation, customization, and reuse
  • new, more powerful database and XML programming model

Let's look at these new features and improvements and explore how you can take advantage of them in your ASP.NET applications. Also, see the sidebar "Namespaces and Assemblies," page 38, for definitions of some terminology that's new to ASP.NET.

Fully Compiled Languages and the CLR

One of the most important differences between ASP and ASP.NET is their underlying technology. ASP is implemented as an Internet Server API (ISAPI) DLL (asp.dll) that intercepts and processes requests for .asp files. The DLL parses through the requested file and interprets any ASP code it finds, then returns the combined result of any static HTML the file contains and any output from executing the interpreted code. ASP developers who want to control the output their pages send to the browser are largely limited to the methods and properties of ASP's Response object.

ASP.NET is also implemented as an ISAPI DLL (aspnet_isapi.dll). This DLL intercepts requests to Microsoft IIS for ASP.NET pages (these pages use the .aspx extension) and passes them to the ASP.NET worker process, which fulfills the request.

ASP.NET uses compiled, rather than interpreted, languages. So instead of VBScript or JavaScript, developers can write code in Visual Basic.NET (VB.NET), C#, JScript.NET, or any other .NET-compatible language. ASP.NET also gives developers much greater control over the Request-Response cycle. You can create HttpHandlers to provide custom handling of HTTP requests and HttpModules to provide custom support services for your applications. In fact, ASP.NET implements session state as an HttpModule; in ASP, session-state support is integrated in ASP itself. Implementing session state as an HttpModule lets you disable session state or even replace it with your own custom session-state HttpModule.

Underlying the new technologies of ASP.NET is the .NET Common Language Runtime (CLR), which works with all .NET languages. With ASP.NET, you don't have to write and compile VB code that requires a VB runtime or write Visual C++ (VC++) code that requires the Microsoft Foundation Classes (MFC) runtime. All your application's executable code, whether you write it in VB.NET, C#, JScript.NET, Managed C++, or another .NET language, is ultimately executed by a single runtime, the CLR. All the language compilers in the .NET world compile your code into language-neutral intermediate language (IL). The CLR then executes the IL, just-in-time (JIT)—compiling the IL code into processor-specific binary code. One distinct advantage of this model is that it lets you create, in any .NET language, classes that any other .NET language's classes can inherit. Another advantage is that this model enables cross-language debugging.

Simplified Programming Model

ASP.NET also introduces a new Web-programming model that's based on the highly successful—and highly productive—VB model. In this new model, instead of working with static HTML code and scripts within a page, you can use ASP.NET's new Server Controls. Server Controls are tag-based controls, similar to VB controls (e.g., TextBox, Label), that provide simple programmability and built-in support for managing their own state. Server Controls provide programmability on the server while rendering cross-browser—compatible HTML to the client, so any HTML 3.2—compatible browser can use these controls (note that some controls can also optionally render Dynamic HTML—DHTML—content for uplevel browsers).

In the Visual Studio.NET (VS.NET) environment, you can place controls visually on the page in much the same way as you can in VB. Then, you can write server-side code to handle the events these controls expose. Listing 1, shows an ASP.NET page that creates Label, TextBox, and Button Server Controls. Note that you must enclose Server Controls within a set of

tags with the runat="server" attribute if you want to take full advantage of ASP.NET features such as automatic postback handling and automatic management of control state.

You implement Server Controls just as you do other HTML tags, except that you preface them with the asp: namespace indicator. Two important attributes that Server Controls use are the id attribute, which specifies a name by which your server-side code can refer to the control, and the runat attribute, which is required for all Server Controls (and is always set to the literal server). Figure 1 shows the output of Listing 1.

ASP.NET also exposes server-side events that developers can write event handlers for, including Page_Load and Page_Unload. ASP.NET automates the process of handling postbacks—pages that post to themselves—so one page can both display input forms and process the form input through code you write. ASP.NET pages expose an IsPostBack property that lets you check whether the current request is the result of a postback. Listing 2 expands on the code in Listing 1, adding a handler for the Page_Load event that responds to a postback.

VB developers will probably notice just how VB-like ASP.NET code is. In fact, you could write an event handler for the Click event (analogous to the OnClick event of a VB CommandButton) of the button just like you would in VB, instead of running your code in the Page_Load event handler, because the Button Server Control automatically submits the page. Figure 2 shows the output of Listing 2 after I entered my name in the TextBox and clicked Submit.

Built-in Functionality

ASP's built-in functionality is limited to a small set of server-side COM components that developers can use for a variety of utility functions. These components include the Ad Rotator (which randomly cycles through a specified set of banner ads), the Browser Capabilities component, the FileSystemObject object, and ADO. These components are useful, but until ASP.NET, Web developers who needed access to additional functionality or the Win32 APIs have been forced to purchase third-party components or create their own COM wrappers.

ASP.NET Web applications can take full advantage of the .NET platform, including all the functionality that the .NET Class Library provides. The .NET Class Library is a set of classes in the System and Microsoft namespaces that provides all platform functionality for the .NET platform. The classes are divided into hierarchical namespaces based on function, so locating the class you need is fairly easy. (For example, the Page class that provides the functionality behind each ASP.NET page resides in the System.Web.UI namespace.)

Some of the functionality available from the .NET Class Library includes the ability to

  • send SMTP email through the SMTPMail class (in the System.Web.Mail namespace)
  • create custom images, using the Bitmap class (in System Drawing)
  • access files by using the classes in the System.IO namespace, including the File, Directory, and TextReader classes
  • perform advanced content caching, using the Cache class (in System.Web.Cache; the Page class exposes it as the Cache property)

Listing 3 shows the code that uses the SMTPMail class to let you send email. This code assumes that you've installed and properly configured the Microsoft SMTP service on the Web server. It also assumes that you've installed the GrocerToGo sample MSDE database that's available with the .NET Framework software development kit (SDK) Samples on the Web server and added a few entries to the Customers table.

The code in Listing 3 uses the @ import directive to import the System.Web.Mail, System.Data, and System.Data.SqlClient namespaces. This directive lets you refer to the members of these namespaces—including the MailMessage, SMTPMail, SqlConnection, SqlCommand, and SqlDataReader classes—simply by class name. You need one @ import statement for each namespace you're importing into your page. The code uses a series of ASP.NET Server Controls to collect user input, then processes that input in the Page_Load event when the client posts the page back, including retrieving email addresses from the Customers table of the GrocerToGo sample database if the Send To Mail List? checkbox is selected. The C# code in Page_Load creates an instance of the MailMessage class called myMail, sets the necessary properties (you need to substitute a valid email address for the From property), adds the list of email addresses from the database if necessary, then uses the SMTPMail.Send method to send the mail. (Note that if you're using a server other than the local server, you can use the SMTPServer property of the SMTPMail class to specify which server to send the mail from.) Figure 3 and Figure 4, show the output of the web.config ASP.NET configuration file in Listing 4, before and after a user sends mail.


ASP.NET also features dramatic improvements in performance and scalability. Performance improvements come both from the fact that the languages used are compiled, rather than interpreted, and from Microsoft's rewrite of the ASP execution engine. ASP.NET improves scalability by supporting two new session-state modes (through a new ASP.NET State NT Service or through SQL Server). Both modes let you share session state across multiple servers within a Web farm, breaking the limitation that the ASP session state imposed. Using the ASP.NET State service, you can assign a single server to manage session state for an entire farm of ASP.NET servers. Using the ASPState SQL Server database (which you can set up with the InstallSqlState.sql batch in the .NET Framework installation directory), you can share session-state information across a Web farm. You can further improve the reliability of session state by using clustering for the SQL Server that's managing session state.

ASP.NET also provides substantial manageability improvements through a new configuration system. Management of ASP.NET configuration is provided through hierarchical XML-based files. Each server has a master configuration file, machine.config, which contains the default settings for all .NET applications on that machine. Each Web application can have one or more files called web.config (each in its own folder) that can override the settings of the machine.config file (or any web.config files in a parent folder). In this way, you can easily set machinewide and application-wide configuration settings, such as session-state configuration, while retaining granular control over such settings as authentication and authorization, error handling, and page attribute defaults. Listing 4 shows a typical web.config file.

A major drawback of ASP is that ASP applications tend to become a mess of spaghetti code and include files, making maintenance and debugging a nightmare. ASP.NET has some substantial improvements that help you avoid this problem. Although you can write spaghetti code with ASP.NET, these improvements mean that you don't have to.

ASP developers need to be aware of one change that will break some existing ASP pages you migrate: ASP.NET doesn't let you put functions inside the <% %> render blocks. You need to place all server-side functions within a

Sponsored Introduction Continue on to (or wait seconds) ×