Exchange SQL And IIS- P158 pdf
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (322.42 KB, 5 trang )
762 Chapter 14 • The Extensible Core Server
Figure 14.14 Native Module Deployed From IIS Manager
7. Once fi nished you’ll see the list of modules installed. You can change the view to the type
of modules and then you will see that MyModule is installed as a native module, as shown
in Figure 14.14.
The Extensible Core Server • Chapter 14 763
Manually Installing a Native Module
Manually deploying a native module is easier than it sounds. First, the .dll that accompanies the
global module must be copied to the IIS server. After that, all it takes is editing the applicationHost.
confi g fi le through any text editor such as Notepad, and entering the module information into the
<globalModules> section The following example shows you how to install a newly created native
module manually:
<add name=“MyModule” image=“c:\native\iis7nativemodule.dll”/>
As seen earlier, Figure 14.8 shows exactly how the aforementioned module would appear in the
applicationHost.confi g fi le if it were a global module.
Enabling Managed Code
(ASP.NET ) in IIS 7.0
For the fi rst time, managed code is a fi rst-class citizen in IIS 7.0. In previous versions
of IIS, managed code developers could not access data early in the request-processing
cycle, because the IIS pipeline owned the area. Only when IIS sent the request (invoked)
to ASP.NET could managed code act upon the request using a Hypertext Transfer
Protocol (HTTP) module. In IIS 7.0, a managed module has the same level of access
to the request processing events as a native module has, and gives developers greater access
to events.
It is important to understand how to enable managed code (i.e., webengine.dll ), how to access
request processing events and the implications of doing so.
Previously, ASP.NET features could not be applied to IIS content types (e.g., forms authentication
for static fi les).
In versions before 7.0, managed code could not access the pipeline directly. It depended on
IIS sending the request to ASP.NET, and then the managed code could act upon the request. When
combined with ASP.NET, the IIS 6.0 model produced a lot of duplication, such as Universal
Resource Locator (URL) mapping, authentication, and handler mapping. This meant having to
confi gure services in two different places.
764 Chapter 14 • The Extensible Core Server
In the previous sections, we talked about and demonstrated how to install native modules in IIS
7.0. The following sections talk about and demonstrate the same with managed code. If you enable
managed code in IIS 7.0, you must understand the iHttpModule interface and how its behavior
depends on what mode the application pool is running in. We briefl y go over both Integrated Mode
and Classic Mode and when to use them.
iHttpModule Interface Support
For those unfamiliar with ASP.NET, here is a brief overview. ASP.NET is a programming model
from Microsoft used for developing dynamic Web sites and Web applications. It was fi rst released
in 2002 with Visual Studio.NET. As part of the .NET Framework, which succeeded the older
Active Server Pages (ASP) technology, ASP.NET is built on the Common Language Runtime (CLR)
and supports numerous programming languages such as, but not limited to, C#, VB.NET, and
JScript.
ASP.NET provides an interface for developers in IIS called iHttpModule. In IIS 6.0,
iHttpModule housed such events as URL mapping, authentication, and handler mapping, hence
a separate pipeline that could be used only for files with .aspx and .asmx extensions, not for
other content such as static files.
The good news for developers of managed code is that a second pipeline is not needed.
IIS 7.0 supports the iHttpModule interface, but now features powered by managed modules can
be applied to all requests to the server, and it is handled by a single request pipeline. Unlike native
modules, managed modules can be deployed with content. In IIS 7.0, managed modules are loaded
in two ways:
■
via webengine.dll, which is supported in integrated mode
■
via isapimodule.dll, which is supported in classic mode
We cover more about the supported modes of IIS 7.0 in the next two sections. Extensibility in
IIS 7.0 is now available to developers writing managed code. Before deploying a managed module,
ASP.NET must be installed on the IIS server. Figures 14.15 and 14.16 show where to enable
ASP.NET on Microsoft “Longhorn” Server and Windows Vista, respectively. The sample code used
for demonstration purposes is from the “IIS Managed Module Starter Kit,” which is provided for free
by the Microsoft IIS Team and can be downloaded from www.iis.net/downloads/default.
aspx?tabid=34&i=1302&g=6
Figure 14.15 Adding ASP.NET to “Longhorn” Server
Figure 14.16 Adding ASP.NET to Windows Vista
766 Chapter 14 • The Extensible Core Server
In Figure 14.17, you see some of the code for the managed module, which is written in C#.
Notice IHttpModule in the code. Even if you weren’t aware of the programming language used,
this line shows that we are looking at a managed module and not a native one.
Although we will not go into the details of the code, it should be pointed out that the class
MyModule’s primary function is to register for event(s) that happen in the unifi ed pipeline and then
perform when IIS invokes the module’s event handlers for its events. The Init statement sends up the
module’s event handler to the appropriate pipeline events. The Dispose line is used to clean up any
resources after the module’s instance is discarded.
Figure 14.17 Managed Code in C#
