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 . 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. 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. 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