Exchange SQL And IIS- P159 docx

After the module is added, it will appear in the list as a Managed Module under IIS Manager, as shown in Figure 14.20.. Please note that no managed modules will ever be added to the se

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

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

Figure 14.19 Entering Managed Module Information

Figure 14.20 List of Managed Modules From IIS Manager

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

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