Exchange SQL And IIS- P159 docx

The Extensible Core Server • Chapter 14 767 After the developer compiles his or her code, the module is stored in a .dll fi le. In this case, it is named MyIIS7Modules.dll. Figure 14.18 shows the web.confi g fi le for this application. Figure 14.18 web.confi g 768 Chapter 14 • The Extensible Core Server Once the code is compiled, you must deploy the module. Just as we did with the native module earlier in this chapter, copy the newly compiled .dll fi le somewhere on the IIS Server. In this example, we’ve copied it to the C:\Managed directory. Now copy the web.confi g fi le onto the server in the %systemroot%\inetpub\wwwroot directory. Open up IIS Manager (you can also deploy this with AppCmd.exe) and go to Modules. Under Actions, choose Add Managed Module, and then enter the information as shown in Figure 14.19. NOTE This application doesn’t do anything, so for display purposes only, we chose System.Web.Profi le.Profi leModule. After the module is added, it will appear in the list as a Managed Module under IIS Manager, as shown in Figure 14.20. You can also verify that it has been deployed by checking the <modules> section in the applicationHost.confi g fi le as shown in Figure 14.21. Please note that no managed modules will ever be added to the <globalModules> section, and that managed modules will always be loaded in the <modules> section. Shortcut… Managed Code Modules Managed code modules don’t have to be compiled by the developer. Simply take the application’s logic in its fi le format (ex: .cs for C#) and drop it somewhere in the app_code directory on the server, and then ASP.NET will pick it up at runtime and compile it for you The Extensible Core Server • Chapter 14 769 Figure 14.19 Entering Managed Module Information Figure 14.20 List of Managed Modules From IIS Manager 770 Chapter 14 • The Extensible Core Server Figure 14.21 applicationHost.confi g File <modules> section As we mentioned earlier, managed modules are loaded in IIS 7.0 in two ways and in two modes: integrated mode, which loads managed modules via webengine.dll, and classic mode, which loads via isapimodule.dll. Let’s examine each. Integrated Mode Integrated mode in IIS 7.0 refers to the ability of managed code to have access to the unifi ed pipeline. As mentioned earlier in this chapter, ASP.NET modules now have access to all content, not just from .aspx or .asmx fi les. So what actually creates the parity between managed code and native code in IIS 7.0? The answer is webengine.dll. Webengine.dll is a native code module that resides under the <globalModules> section of the applicationHost.confi g fi le. It acts as a shim that allows managed code direct access to the fully integrated and unifi ed pipeline. Developers using managed code still use the iHttpModule, but they are actually working with the shim. Webengine.dll allows managed code to be treated as a fi rst-class citizen in IIS 7.0. To use it you must run in Integrated Mode. The Extensible Core Server • Chapter 14 771 Which mode you run in is determined at the application pool level. You can have some application pools running in integrated mode and others in classic. In Figure 14.22 we are creating a new application pool called MyTestApp. Notice that we can select which mode we want. In this example we’ve chosen Integrated. Figure 14.22 MyTestApp Classic Mode Classic mode provides the same environment that we had in IIS 6.0. IIS 7.0 in classic mode installs both the ISAPI module and the ASPNET_ISAPI.dll ISAPI extension. In IIS 7.0 classic mode, managed modules are loaded using the isapimodule.dll fi le. So, if we have this unifi ed pipeline and the managed code is at the same parity as native code, why would we want to run in classic mode? The simple answer is if you have any custom modules defi ned they may not run in integrated mode. This environment is safe and robust for existing applications, and developers may see no need in converting existing applications. ■ IIS 7.0 offers a new landscape for developers that was never 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. . logic in its fi le format (ex: .cs for C#) and drop it somewhere in the app_code directory on the server, and then ASP.NET will pick it up at runtime and compile it for you The Extensible Core. mode. This environment is safe and robust for existing applications, and developers may see no need in converting existing applications. ■ IIS 7.0 offers a new landscape for developers that was. earlier, managed modules are loaded in IIS 7.0 in two ways and in two modes: integrated mode, which loads managed modules via webengine.dll, and classic mode, which loads via isapimodule.dll. Let’s