Gallery

Configuring ASP.NET

Posted on 20 Feb 2006 at 12:07

Thomas Lee looks at how to manage and configure ASP.NET, together with IIS and HTTP

Each worker process, w3wp.exe, is essentially a self-contained web server. When W3WP starts, it loads all the necessary ISAPI filters and extensions and can service any web app within its Application Pool. Each worker process is isolated from IIS server components and from other web apps in other worker pools.

IIS 6 stores configuration information in the Metabase, an XML file that replaces the binary-format data store used by IIS 5. Since the Metabase is in XML, you can read and edit it using Notepad or any other text editor.

As shown in the screenshot, IIS 6 runs on top of http.sys, the kernel mode HTTP redirector. Whenever a web server receives an HTTP request, http.sys redirects this request to the appropriate worker process, based on its URL. Earlier versions of IIS required all HTTP requests to travel via the main Inetinfo process. http.sys also serves static web pages directly from kernel mode cache, which provides a useful performance boost for static content.

Of course, IIS 6 also supports classic ASP, which allows you to support 'legacy' web apps on Windows Server 2003 and IIS 6. You therefore get useful improvements in performance and reliability by moving to Windows Server 2003 without being forced to upgrade your web apps.

ASP.NET

At its heart, ASP.NET is just an ISAPI filter that resides in the IIS 6 worker process. This filter picks up incoming HTTP requests and processes them. One problem with earlier ASP apps was that the same ASP page contained both the server-side script and the page's HTML layout.

Since code and display logic resided in a single file, complex pages became a nightmare to maintain. ASP.NET solves this problem by implementing what's known as 'code behind'. This separates display logic from processing logic (although you can still mix code and processing if you insist). When processing a request for foo.aspx, for example, a header within foo.aspx tells ASP.NET the details of the code-behind module (for example, foo.aspx.cs), and ASP.NET then loads the appropriate assembly, carrying out any module or just-in-time compilation that it requires.

Deploying an ASP.NET app is as simple as XCopying ASP and code-behind files onto a working web server, along with the necessary configuration files discussed later. There's no complex COM environment to manage, no Registry entries to hack, just XCopy and go. You may need to spend some time installing and configuring IIS, and in locking down Windows for security, but the addition of an ASP.NET app to a working IIS 6 web server is trivial.

Deploying updates is equally easy - just XCopy the updated files and the next time a page is requested ASP.NET recompiles what's needed and runs the updated app. For large complex apps, however, this may not be the best deployment approach (although the nitty-gritty details of deployment I'm going to leave for a separate article). To illustrate, with some help from my developer guru buddies Dave Wheeler and James Winters, I built a simple calculator app using Microsoft's new Visual Web Developer 2005 Express (VWDE), a simplified version of Visual Studio 2005. At the moment, it's free for download (see msdn.microsoft.com).

My calculator app consists of just two files: calc.aspx (the 'application') and calc.aspx.c, the code-behind page. calc.aspx looks like this:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Calc.aspx.cs" Inherits="_Default" %>