When running Web Connection in 64 bit versions of Windows with IIS there are special configuration issues to consider. Web Connection can run both 32 bit and 64 bit modes using two different approaches:
- Web Connection ISAPI DLL (32 bit)
The Web Connection ISAPI DLL is a 32 bit application and requires that the Web Server runs in 32 bit mode. It's possible to switch a 64 bit Web server into 32 bit mode using a Metabase configuration switch, but unfortunately this switch affects all Web Applications on the server.
- The Web Connection Managed Module (32 bit and 64 bit using .NET)
The Web Connection .NET Managed Module allows running the Web Connection connector as a 64 bit application inside of the Web Server. This means that both file based and COM operation can run in 64 bit mode and communicate with the 32 bit FoxPro servers.
Here's a quick overview of the issues involved:
Web Connection ISAPI DLL
If you try to run the Web Connection ISAPI DLL on a 64 bit server without 32 bit compatibility mode enabled any request to the Web Connection DLL will fail with a 500 Server error and this error:
%1 is not a valid Win32 application.
(note that if you use IE default error reporting it will not actually show this error because the error message is too short - you'll only see the 500 Internal Error Page. If you get an error check with a tool like Fiddler, turn off friendly error messages in IE or use another browser to make sure that is the problem)
This indicates that the ISAPI extension is called from a 64 bit server instance. To fix this issue you need to do the following:
Enable 32 Bit operation
Drop to a Command Prompt and execute:
cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 true
This basically enables 32 bit support for all IIS Application Pools. Note that this affects ALL Application Pools, so this effectively disables 64 IIS Applications on IIS.
Reconfigure ASP.NET for the proper 32 or 64 bit version
In addition you may have to fix ASP.NET if it is installed on the server. ASP.NET 2.0 installs an ISAPI filter and that filter needs to be tied to either the 32 bit .NET runtime or the 64 bit version. If the wrong filter is installed you will get a Service is Unavailable error as the Application Pool crashes basically on any request and shuts down.
To set up ASP.NET for 32 bit:
To set up ASP.NET for 64 bit:
Note that this ASP.NET configuration is REQUIRED even if you don't use ASP.NET, but if it is enabled. To check for this go to:
IIS Service Manager | Web Sites | ISAPI Filters
In the list you should see the ASP.NET ISAPI filter if it's active. If it is there you will need to run the above command line appropriate for this version. Or if you don't use ASP.NET at all you can just remove the filter.
The Web Connection .NET Managed Module can run in 64 bit Mode
A few months back I spent quite a bit of time re-writing the ISAPI extension as a .NET HttpHandler in anticipation of IIS 7 which can run .NET modules in its native pipeline. There are a number of advantages to this approach including a much more flexible programming model that makes it possible to provide many more improvements to the connector module that are very difficult to accomplish in the C++ ISAPI environment. Surprisingly performance of the .NET module is on par or even slightly better than the ISAPI extension due to an improved COM pool manager and there are a number of additional management tasks that improve overall administration of the server.
But one huge side benefit of the .NET module is that it can run on IIS 7 in pure 64 bit mode!
The module started shipping with Web Connection 5.20 and later also ships with a .NET HttpHandler that is capable of running in 64 bit mode natively without requiring any changes to the Web Server. The module supports operation both in file and COM modes.
The module works with ASP.NET 2.0 on IIS 6 or as a native HttpHandler in IIS 7.0 and it works without any configuration changes both in 32 and 64 bit mode.
Here is a list of advantages of using the managed HttpHandler:
· More efficient COM Pool Manager
· Support for MTDLL servers for in-process operation (still not recommended though <s>)
· 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 Manager (load/unload/load one/AutoStart)
· 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 (Application Pool) 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 when script maps pointed to the same DLL. In a nutshell, managed code cannot span across IIS Application Pools.
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.
The managed module works both with IIS 7 and any .NET 2.0 capable environment – as long as HttpHandlers are supported (ie. IIS 5 and IIS 6 but also Mono under Linux/’nix) the module can be used.
Setting up IIS 7 for using with the managed module is easy by using the Integrated pipeline. With IIS 7 this model permits true XCOPY deployment with no additional configuration needs - you can simply copy the WebConnectionModule.dll in your BIN directory as part of your Web directory and make a couple of changes in web.config to enable to the module.
Setting up the Managed Module in IIS 7
Here's how to set up a new project and switch to the Managed Module:
· Start out by Creating a new Project in the Management Console (DO CONSOLE)
· Create a project as usual with a custom script map
· When the project has been created go into the IIS Service Manager
· Select the West Web Connection Application Pool
· Click Basic Settings and ensure that the Application Pool is Integrated Pipeline
The WebConnectionModule.dll file is installed in the bin folder of your site and IIS/ASP.NET can automatically detect the assembly there. All that’s left to do is assign scriptmaps to the module.
By default the web.config file that installs with the new project has the module hook ups commented out which in turn results in the ISAPI DLL being used. To switch to using the module open web.config and edit the following section:
<handlers accessPolicy="Script, Execute, Read">
<!-- IIS 7 in Integrated Mode -->
<add name="*.wp_wconnect" path="*.wp" verb="*" type="Westwind.WebConnection.WebConnectionHandler,WebConnectionModule" preCondition="integratedMode,runtimeVersionv2.0" />
<add name="*.wc_wconnect" path="*.wc" verb="*" type="Westwind.WebConnection.WebConnectionHandler,WebConnectionModule" preCondition="integratedMode,runtimeVersionv2.0" />
<add name="*.wcs_wconnect" path="*.wcs" verb="*" type="Westwind.WebConnection.WebConnectionHandler,WebConnectionModule" preCondition="integratedMode,runtimeVersionv2.0" />
<add name="*.wcsx_wconnect" path="*.wcsx" verb="*" type="Westwind.WebConnection.WebConnectionHandler,WebConnectionModule" preCondition="integratedMode,runtimeVersionv2.0" />
<add name="*.wwsoap_wconnect" path="*.wwsoap" verb="*" type="Westwind.WebConnection.WebConnectionHandler,WebConnectionModule" preCondition="integratedMode,runtimeVersionv2.0" />
<add name="*.blog_wconnect" path="*.blog" verb="*" type="Westwind.WebConnection.WebConnectionHandler,WebConnectionModule" preCondition="integratedMode,runtimeVersionv2.0" />
<add name="*.wwd_wconnect" path="*.wwd" verb="*" type="Westwind.WebConnection.WebConnectionHandler,WebConnectionModule" preCondition="integratedMode,runtimeVersionv2.0" />
<!-- end IIS 7 in Integrated Mode -->
This section basically configures each of the script maps you want to use by mapping the request to the managed module. Note that the managed module cannot be accessed directly – ie. there you can’t easily handle wc.dll calls. You can (but it’s not recommended do something like this):
<add name="wc.dll_wconnect" path="wc.dll" verb="*" type="Westwind.WebConnection.WebConnectionHandler,WebConnectionModule" preCondition="integratedMode,runtimeVersionv2.0" />
But you need to configure IIS first to allow .dll requests to fire out of a non bin directory. Not recommended.
As of Web Connection 5.20 all the samples and configuration files have been updated to ALWAYS use scriptmaps – all wc.dll calls have been banned (hopefully <s>).
Note that this is not a complete web.config file – there are a few other settings required unrelated to the module configuration, but those will already be in the file.
You can also run on IIS 5/6 and the process is nearly identical except the script mapping must be done both in IIS’s configuration AND in web.config. You can find out more here.
Although Web Connection is ready to tackle 64 bit servers with this module, keep in mind that your FoxPro server application will continue to run in 32 bit mode (it has to). This is not a problem though as 32 bit Windows can easily run 32 bit FoxPro servers as external applications. What’s interesting is that this actually works for Web Connection COM servers BECAUSE they are EXE servers. It doesn’t work for InProcess servers because they load into IIS and if you use InProc servers you’re back to having to switch the Web Server into 32 bit mode.
So, it looks like this addition will ensure that Web Connection will be able to run on IIS servers for quite some time to come even in COM mode – as long as FoxPro itself can run on the server. I think that’s pretty cool given the relatively little effort that went into creating the new module.