Access to a unifi ed request pipeline now puts managed code in parity with its native brethren.. Integrated mode provides the new features such as the unifi ed request pipeline that both
Trang 1772 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
Trang 2The 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
Trang 3774 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
Trang 4Chapter 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
Trang 5776 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: