Exchange SQL And IIS- P158 pdf

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