Datasheet

With IIS6, it is now possible to set up rules (aka wildcard application maps) that route all HTTP requests
to one or more ISAPI extensions. The set of wildcard application mappings can be prioritized, so it is
possible to have a chain of wildcard mappings. IIS6 also includes a new API for ISAPI extensions to
route a request out of an extension and back to IIS6. The net result is that with IIS6 and ASP.NET 2.0, it is
possible to have a request for a static file flow through the first portion of the ASP.NET pipeline, and
then have the request returned to IIS6, which subsequently serves the file from the file system.
Out of the box though, ASP.NET 2.0 does not configure or use any wildcard application mappings.
ASP.NET 2.0 does include though the necessary internal changes required to flow a request back out to
IIS6. As a result, ASP.NET 2.0 has this latent ability to integrate with and use wildcard application map-
pings for some very interesting scenarios. As mentioned earlier, it is possible for an ISAPI extension to
perform some processing for a requested file without actually understanding the requested file format.
An interesting new avenue for integrating ASP.NET 2.0 with static files and legacy ASP code is discussed
later in this book in Chapter 6, “Integrating ASP.NET Security with Classic ASP,” The techniques in that
chapter depend on the wildcard application mapping functionality of IIS6.
aspnet_isapi.dll
After a request reaches aspnet_isapi.dll ASP.NET takes over responsibility for the request. IIS6 itself
knows nothing about managed code or the .NET Framework. On the other hand, the core processing
classes in ASP.NET (
HttpApplication and the specific handlers that run .aspx pages, .asmx Web
Services, and so on) do not possess the ability to reach out and directly consume an HTTP request.
Although the vast majority of ASP.NET is managed code, the ISAPI extension plays a critical role in
bridging the native and managed code worlds.
The responsibilities of the ISAPI extension fall into two broad areas:
❑ Starting up an application domain so that managed code associated with an application can run
❑ Setting up the security context for each request and then passing control over to the managed
portion of ASP.NET
Understanding some of the important portions of application domain startup is important for later dis-
cussions on trust levels and configuration. Information about the per-request initializations and handoff
will be covered in Chapter 2.
ASP.NET includes several classes in the
System.Web.Hosting namespace that can be used by applica-
tions that want to host ASP.NET. If you use the file-based web project option in Visual Studio 2005, you
are using a standalone executable (
WebDev.WebServer.exe located in the framework install directory)
to host ASP.NET. Also, if you search on the Internet several articles and sources demonstrate how to
write console and Winforms applications to host ASP.NET. However, most ASP.NET developers are writ-
ing web applications and expect their applications to be hosted on a web server. As a result, you can
think of
aspnet_isapi.dll and its supporting managed classes as the default implementation of an
ASP.NET host.
14
Chapter 1
04_596985 ch01.qxp 12/14/05 7:46 PM Page 14