Starting with Web Connection 5.25 Web Connection ships a .NET managed handler/module that completely duplicates - and enhances - the ISAPI DLL that has been Web Connection's main stay. The module provides a much cleaner design for the connector interface and much easier development which in turn allows us to provide more advanced features in the module. The new module also turns out to be more efficient than the ISAPI module in COM operation.

Here is a list of advantages of using the module:

• More efficient COM Pool Manager
  
• Support for MTDLL servers for in-process operation
  
• More flexible in the server interface - many small improvements
  
• Native IIS 7 Integrated Pipeline Support
  
• Pure XCopy deployment of the module with IIS 7 through web.config
  
• Support for running on 64 bit Web Servers (for the module - VFP servers still are 32 bit!)
  
• Possibility to run on non-Microsoft platforms with Mono
  
• Develop without IIS using the Visual Studio Web Server
  
• Improved File Based Server Management (load/unload/load one/AutoStart/AutoReload of instances)
  
• More discoverable configuration
  

There's also one downside to using the module which relates to the way that ASP.NET and IIS 7 separate IIS applications:

• On pre-IIS 7 .NET 2.0 must be installed and ASP.NET configured
  
• An instance of the module is tied to an IIS 'Application' - you cannot share one set of COM servers across multiple 'Applications' the way you can with the DLL.
  

Servers are tied to a single Web IIS Application

The latter issue shouldn't be a problem for new development, but it can be an issue for existing applications that share multiple virtual directories for a single set of servers only in COM mode. For COM based servers the COM objects are tied specifically to an Application/Virtual directory. This is due to ASP.NET's application boundary which is tied to a virtual directory/IIS Application.

This means if you have two separate applications that both use the same COM server they will create two sets of servers rather than a single set as the Web Connection ISAPI DLL did as long as script maps pointed to the same DLL.

There's a workaround for this scenario: You can create a hierarchy of directories that are based on a physical disk layout and so don't need to rely virtual directories for separation. So if the root is configured for the module any non-virtual directories below it share that ASP.NET AppDomain. It requires some forethought and organization which is easy to do knowing this issue exists. However, it can be potentially difficult to achieve if you already have existing shared applications in place.