772 Chapter 14 • The Extensible Core Server Summary IIS 7.0 now offers developers a better environment. It’s easier than ever to extend IIS using either native or managed code. Access to a unifi ed request pipeline now puts managed code in parity with its native brethren. IIS now ships with over 40 modules built-in for developers to take advantage of. Extending IIS 7.0 with native modules is remarkably less stressful. No longer are native code developers dealing with the complexities of creating ISAPI fi lters and extensions. They now are able to make use of the same APIs that Microsoft used in creating IIS 7.0. Deployment of native modules is also easier. They can be placed anywhere on the server that they are running on. Developers and administrators also have the choice of how they want to deploy these modules. Deployments can be done from the AppCmd.exe command line utility, the IIS Manager, or by editing the applicationsHost.confi g fi le. There are more options for developers using managed code. Managed modules can run in two different modes under IIS 7.0. Integrated mode provides the new features such as the unifi ed request pipeline that both native and manage code share. Managed code has full access to all content not just that of ASP.NET. This available for managed modules through webengine.dll, a native global module that acts as a shim so that managed code can have direct access to the pipeline. Developers who have applications that rely on the old IIS 6.0 architecture can do so by setting their application pools to run in classic mode. This provides the same pipeline behaviors and the limitations that come with IIS 6.0. It also provides a stable and secure environment to work in. In IIS 7.0, Microsoft has created a much friendlier environment for developers and administrators alike. Solutions Fast Track Understanding Development Advantages in IIS 7.0 ˛ IIS 7.0 offers a new landscape for developers never before available in IIS. ˛ In constructing IIS 7.0, Microsoft ensured that core processing of requests was removed from features that were implemented in individual modules. ˛ Access to early pipeline events, such as authenticating requests, were never possible for managed code developers until IIS 7.0. ˛ IIS 7.0 is easier to extend than ever before for developers. ˛ Because of the unifi ed pipeline, managed code is no longer treated as a second-class citizen. Extending IIS 7.0 with Native Modules ˛ Extending IIS with C or C++ no longer requires the creation of ISAPI extensions. ˛ Native code developers now have access to the same set of APIs that Microsoft used in developing IIS 7.0 ˛ Deployment of native modules is easier because of tools such as AppCmd.exe and IIS Manager, or they can be done manually by editing the applicationHost.confi g fi le. The Extensible Core Server • Chapter 14 773 Enabling Managed Code in IIS 7.0 ˛ ASP.NET has access to all content types. ˛ Application pools can run in one of two modes: Integrated or Classic. ˛ Integrated mode takes advantage of the new features and capabilities of IIS 7.0. ˛ Managed code running under integrated mode makes use of a native module called webengine.dll, which provides direct access to the unifi ed pipeline. ˛ Classic mode provides the same environment of IIS 6.0 with all the stability and security that developers used for their legacy applications. 774 Chapter 14 • The Extensible Core Server Frequently Asked Questions Q: If managed code now has the same direct access to the request pipeline as native code, then why would you create native modules? A: Performance for one. Native code will always run faster with less overhead than managed code. Second, managed modules are application-specifi c, where as if you need to create a global module, then you must do so in native code. Q: Which method is best when deploying native modules (AppCmd.exe, IIS Manager, or manually) ? A: It depends. If you are deploying multiple native modules at one time, then creating a script that makes use of AppCmd.exe might be your best bet. IIS Manager is an excellent choice for those who prefer a more task-oriented way of doing things. A person might deploy a native module manually if they are comfortable editing confi guration fi les and feel using either method mentioned earlier would slow them down. Q: If I run my managed code module in classic mode, would I need to deploy webengine.dll in the applicationHost.confi g fi le? A: No. Only if you choose to run your code in Integrated Mode would you need webengine.dll. It allows managed modules direct access to the request pipeline. Q: I have some applications that must run in classic mode, but I want to create newer applications that take advantage of the changes in IIS 7.0. Can I have some application pools running in classic mode and others in integrated mode on the same box? A: Yes. When you add your application pool, choose which mode you want. In IIS Manager you will see the coexistence of integrated and classic mode pools. Q: Why can’t I have a managed module in the <globalModules> section of the applicationHost. confi g fi le? A: Only native modules can reside in the <globalModules> section. Managed modules can only be set at the application level, not the global level. 775 Chapter 15 Solutions in this chapter: ■ Introducing ApplicationHost.confi g ■ Enabling Delegated Administration in IIS 7.0 ˛ Summary ˛ Solutions Fast Track ˛ Frequently Asked Questions Get Started with IIS 7.0’s Confi guration 776 Chapter 15 • Get Started with IIS 7.0’s Confi guration Introduction Since IIS 4.0, administrators have grown to love the metabase, whereas developers did quite the opposite. The metabase offered a complex, ID-based system, with tight security. In fact, to have write access to the metabase required that a user account have administrative privileges on the Web server. In IIS 7.0, out with the old (metabase) and in with the new (applicationHost.confi g, web.confi g) was the order of the day. IIS 7.0 built on the successful and highly popular .confi g infrastructure ASP. NET used to build the next-generation Web server confi guration. The major items introduced to this XML confi guration were the System.WebServer and the System.ApplicationHost namespaces designed to give administrators and developers a multitude of access points to confi guration. IIS 7.0 also enables system administrators (Windows administrators) to delegate sections of the confi guration to nonadministrators easing the burden of management on themselves. Beyond that, Web farm synchronization has never been easier than it is with IIS 7.0’s distributed confi guration capabilities. Introducing ApplicationHost.confi g The metabase lived a long, strong, and good life. It wasn’t until security, and developer productivity, came to the forefront that the metabase’s shortcomings were exposed. The metabase was not architected in a manner that offered an easy, yet productive mechanism to delegate write capabilities to nonadministrator users. Furthermore, it offered undesirable child behavior not enabled at the parent level by copying the entire parent metadata to the child—potentially doubling the size of the metabase. With the new confi guration, called ApplicationHost.confi g, IIS 7.0 natively supports the IIS 6.0 confi guration while also supporting these new robust features such as distributed confi guration, as well as delegated confi guration. It is important that we outline in this section the prevalent pieces of the new confi guration, including System.WebServer and System.ApplicationHost. The latter is unable to be edited by anyone other than system administrators (Windows), whereas the former can be unlocked and edited as part of the application deployment process. We will focus on offering good clarifi cation between <sites>, <globalModules>, and other ApplicationHost-enabled features. For years the metabase has served the world of IIS well, but as the saying goes, “the only constant in life is change,” and change is exactly what IIS 7.0 offers. The old metabase was not designed in a way that was easy to read, and it did not provided a mechanism for delegating control to nonadministrators. The ApplicationHost.confi g fi le has now replaced the metabase as the primary store for IIS confi guration and settings. It has defi nitions for locking down most IIS sections to the global level so that by default they are not overridden by lower level web.confi g fi les. The ApplicationHost.confi g fi le is an XML fi le that resides in the %windir%\ system32\ inetsrv\ confi g directory. It stores lists of sites, applications, virtual directories, logging, caching, and so on. It also can be viewed or modifi ed in any text editor. The ApplicationHost.confi g fi le contains many sections. The fi rst section you come to in the ApplicationHost.confi g fi le and one of the most important is <confi gSections>. This section registers all IIS and Windows Activation System (WAS) sections. It contains a list of all other sections in the fi le. Figure 15.1 shows the <confi gSections> section and the section groups of <system.applicationHost> and <system.webServer> of the ApplicationHost.confi g fi le. Other sections to note from the ApplicationHost.confi g fi le are: . behaviors and the limitations that come with IIS 6.0. It also provides a stable and secure environment to work in. In IIS 7.0, Microsoft has created a much friendlier environment for developers and. they are running on. Developers and administrators also have the choice of how they want to deploy these modules. Deployments can be done from the AppCmd.exe command line utility, the IIS Manager,. developers and administrators alike. Solutions Fast Track Understanding Development Advantages in IIS 7.0 ˛ IIS 7.0 offers a new landscape for developers never before available in IIS. ˛ In constructing