747
Chapter 14
Solutions in this chapter:
■
Understanding Development Advantages
in IIS 7.0
■
Extending IIS 7.0 with Native Modules
■
Enabling Managed Code in IIS 7.0
˛ Summary
˛ Solutions Fast Track
˛ Frequently Asked Questions
The Extensible
Core Server
748 Chapter 14 • The Extensible Core Server
Introduction
There has never been so much excitement for a Microsoft Web server as there is for IIS 7.0. It is easy
to understand why, when developers across all languages have the same freedoms. The parity stopped
when a developer using ASP.NET attempted to garner full control of requests incoming to the Web
server. This freedom wasn’t allowed unless a developer knew C++ and was familiar with the complex
Internet Server Application Programming Interfaces (ISAPIs) that were shipped with IIS 1.0 and later
versions. These rules are changed with IIS 7.0, as developers can choose their languages of choice, and
managed code developers have the same access to the same events as their C/C++ counterparts. The
IIS 7.0 core server hasn’t met a developer it doesn’t like.
Understanding Development Advantages
in IIS 7.0
We focus on administration more than development, but one cannot avoid the fact that the landscape
for development on IIS has drastically increased with IIS 7.0. Administrators should know that
IIS 6.0 and previous versions were in a semi-open system where developers were offered a complex
mechanism to modify the behavior of the Web server via ISAPI fi lters. In IIS 7.0, that barrier has

been broken down and is now open to developers who write both native (C/C++) and managed
(VB.NET, C#) code.
It is important to understand how native code modules are implemented and installed in IIS 7.0.
Beyond that, an administrator needs to understand the implications of introducing managed code
into IIS 7.0 and furthermore, how to enable them.
Although most administrators typically do not create modules themselves, it is important
that they understand from a high level what changes and improvements have been made in the
architecture of IIS 7.0, in particular as it applies to developers and the improvements that they
will experience.
As mentioned in Chapter 12, the core server in IIS 6.0 was monolithic with two request
pipelines: one for native modules and another for managed modules. The previous platform didn’t
provide developers with the environment they desired. Developers who used managed code such as
C# or VB.NET saw their requests treated as second-class citizens, thereby not having the same
freedoms as those who wrote native code such as C/C++. All was not rosy for developers using
low-level languages either; they experienced a diffi cult and cumbersome task in extending IIS 6.0
by creating complex ISAPI fi lters and extensions. All of this has changed in IIS 7.0.
Administrators and developers alike need to understand that IIS 7.0 resolves these issues with a
more modular architecture and unifi ed pipeline. Whether a developer uses native or managed code,
they have full access to the same events. IIS 7.0 provides a friendlier place for developers of all types.
Developers need to know what is involved in extending IIS 7.0 through building native and managed
modules, and administrators need to understand the different methods that are available for deploying
them.
IIS 7.0 supports two different environments brought under the concept of modes. Understanding
how the two modes apply to application pools and when to use either is important for both
The Extensible Core Server • Chapter 14 749
SOME INDEPENDENT ADVICE
The tools provided at Windows Sysinternals are used by many at Microsoft and have
been for years, so it made sense when Microsoft acquired the group headed by
Windows guru Mark Russinovich. The tools created by this group are some of the
best in the industry. What’s even better is that they can be downloaded for free at

www.microsoft.com/technet/sysinternals/default.mspx.
administrators and developers. The following sections examine each of the concepts mentioned in this
section and go through two demonstrations.
Inside the Unifi ed Pipeline
In earlier versions of IIS (6.0 and earlier), the development of .NET application components was
allowed through ASP.NET. This was integrated via ISAPI extensions; therefore, administrators ended
up having two separate pipelines—one for native code (ISAPI fi lters and extensions) and a second for
managed code (ASP.NET). Requests to non-ASP.NET content such as static fi les were not visible to
ASP.NET under IIS 6.0 and earlier. When running in integrated mode, IIS 7.0 allows ASP.NET to
integrate with the core server, thus providing a unifi ed pipeline for both native and managed code
and allowing ASP.NET modules to be used for requesting static fi les and other content. No longer do
developers have to depend on an ISAPI intermediary, which is diffi cult to write and must be done in
C or C++. Now managed code can control every request going to the application to which it is
mapped. Figure 14.1 depicts the core server in IIS 7.0. Notice that both native and managed code
have the same access to the same events.
BEST PRACTICES ACCORDING TO MICROSOFT
When you are examining the modules loaded in w3wp.exe, Microsoft recom-
mends using the Windows Sysinternals process explorer. Opening up the worker
process in process explorer, developers can examine their modules in action,
whether they are loading or not, and determine the size of their footprint in
memory.
Through the use of the new native application programming interfaces (APIs) or ASP.NET, modules
can be developed to extend IIS 7.0. Native code itself interacts with the IIS 7.0 request pipeline directly,
without any intermediaries or shims. The advantage of this is speed and improved performance.
Programmers who are used to writing ISAPI fi lters and extensions now have the option of using the new
publicly available APIs for creating their new modules. These modules allow C and C++ programmers
more freedom because they are not being bound by the tight restrictions in writing ISAPI code.
750 Chapter 14 • The Extensible Core Server
Extensibility in IIS 7.0 is also provided to manage code via webengine.dll. As we will see later, this
native global module provides managed code direct access to the pipeline when running in integrated

mode. Isapimodule.dll maps ISAPI calls as though modules were running in the older IIS 6.0 and earlier
model in classic mode. There will be more about integrated mode versus classic mode later in this chapter.
Modules and Kits
Microsoft provides sample modules and starter kits for both administrators and
developers of IIS 7.0. Administrators can walk through adding and deleting modules,
while developers can use the sample modules as examples for their own. These can be
downloaded at www.iis.net.
Shortcut…
w3svc
Http.sys
Native or Managed Module
Handlers
Native Handler Managed iHttpHandler
Static file Isapi ext *.aspx Trace.axd
Integrated Pipeline
Other native
modules
Basic auth
Digest auth
Windows auth
Other managed
modules
Url auth’z
Role mgr
Forms auth
End
Log
Update cache
Release state
Execute handler

Pre -execute handler
Acquire state
Map handler
Resolve cache
Authorize
begin
Native Module
iHttpModule
Figure 14.1 IIS 7.0 Core Server
The Extensible Core Server • Chapter 14 751
Extending IIS 7.0 with
Native (C\C++) Modules
Microsoft developers changed the way they developed the IIS Web server in IIS 7.0 by ensuring that
they used the same APIs that were used by their customers. In IIS 7.0, the native APIs used to build
features on top of the core server are the same as those used by developers. They are built and
enabled the same way, and they are installed similarly.
It is important to know how a developer (or administrator) begins building a simple native
module, but much more important to know how to install it correctly in IIS 7.0.
C and C++ developers do not have to deal with the diffi culties of writing and debugging ISAPI
fi lters and extensions anymore. Developers also do not need to create ISAPI code; anything they need
can be accomplished by creating a module. As mentioned earlier, native code programmers can use
the new server APIs that Microsoft developers used in developing IIS 7.0. Deployment is also much
easier than in the past. It is important for administrators to understand how a developer goes through
building native modules and what it takes to add them to IIS 7.0.
BEST PRACTICES ACCORDING TO MICROSOFT
Before modifying the applicationHost.confi g fi le, Microsoft recommends backing the
fi le up. If after adding a native module IIS becomes unstable, it will be easier to
restore to the previous fi le. Here is an example of performing such a backup using
AppCmd.exe.
Appcmd.exe add backup <name of backup>

SOME INDEPENDENT ADVICE
As an administrator, you may need to add modules on a regular basis. If this is the
case, create a naming standard for your backups that makes sense to you. You may
want to use a naming standard that mentions the module you are about to deploy.
For instance, if you are about to deploy a module called MyModule, you can put it
in the name of the backup. Below is an example of using the module’s name, its
version, and the date. This way you know that this backup was done before you
added the module MyModule version 1.0.
Appcmd.exe add backup MyModule-1.0-03-1007
Building Native Modules
Although server extensibility can now be done using managed code and the ASP.NET APIs, there
still are reasons developers may want to create modules via native code. One of the biggest reasons is