Exchange SQL And IIS- P159 docx
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 (409.5 KB, 5 trang )
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.
