Trying to figure out the cleanest approach for moving our customer sites away from ISAPI.
Typically their IIS setup looks something like this:

What I've done is to drop a copy of web.config into the wwwroot\wconnect folder with the contents shown below (after ensuring that webconectionmodule.dll resides in the bin folder). I then adjust the entries to reflect their existing wc.ini settings, reset IIS, and things are good to go under .NET.

The one drawback is that attempts to call mapped pages must include "wconnect" in the url path. (i.e. mysite.com/wconnect/mymethod.awp works but mysite.com/mymethod.awp will fail) That's not a problem for some customers who are used to using the expanded path, but others prefer to use the cleaner url. While still others may use both - some links have wconnect, some do not. This mix amd match approach worked fine under ISAPI since the handler mappings used an absolute path to point to wc.dll - any call to a mapped .awp page would work regardless of whether wconnect was in the path.

Is there a way to replicate that behavior under .NET? Hopefully without having to do a major revamp of their IIS configuration? I am facing well over 100 legacy customer sites that are still running under ISAPI so want to keep things as simple as possible.

--stein

Contents of wwwroot/wconnect/web.config:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
  <configSections>
    <section name="webConnectionConfiguration" type="System.Configuration.NameValueSectionHandler,System,Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
  </configSections>
  <system.webServer>
    <handlers>
      <add name="Aceweb" path="*.awp" verb="*" type="Westwind.WebConnection.WebConnectionHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode" />
      <add name="WCScript" path="*.wcs" verb="*" type="Westwind.WebConnection.WebConnectionHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode" />
      <add name="WCPage" path="*.wc" verb="*" type="Westwind.WebConnection.WebConnectionHandler" resourceType="Unspecified" requireAccess="Script" preCondition="integratedMode" />
    </handlers>
    <httpErrors errorMode="Detailed" />
  </system.webServer>
  <webConnectionConfiguration>
    <add key="MessagingMechanism" value="Com" />
    <add key="ComServerProgId" value="aw3.acewebserver" />
    <add key="ServerCount" value="1" />
    <add key="AutoStartServers" value="True" />
    <add key="ComServerLoadingMode" value="LoadBased" />
    <add key="TempPath" value="c:\temp\wc\" />
    <add key="TempFilePrefix" value="WC_" />
    <add key="Timeout" value="300" />
    <add key="UseCustomManifestLoading" value="False" />
    <add key="AdminAccount" value="ANY" />
    <add key="AuthenticationMode" value="Default" />
    <add key="AdminPage" value="/wconnect/admin/admin.aspx" />
    <add key="ExeFile" value="C:\inetpub\aceweb\aw3.exe" />
    <add key="UpdateFile" value="C:\inetpub\updates\aceweb\aw3.exe" />
    <add key="LogDetail" value="False" />
    <add key="ValidateRequest" value="False" />
    <add key="PassAspNetContext" value="False" />
    <add key="MessageDisplayFooter" value="Page generated by Web Connection IIS Connector Module" />
    <add key="UseStaComServers" value="False" />
    <add key="LiveReloadEnabled" value="False" />
    <add key="LiveReloadExtensions" value=".wc,.wcs,.html,.htm,.css,.js,.ts" />
  </webConnectionConfiguration>
</configuration>

I'm not sure I understand what's not working...

I think the best way to migrate is to make sure you change all your wc.dll links to wc.wc (or wc.awp). Assuming the wc.dll calls are in the root (and not in to your bin folder as in /bin/wc.dll) you can do a wholesale search and replace for wc.dll to wc.wc (or wc.awp) and have everything go through the .NET handler. Another option is to map *.dll to the same .NET handler - that would also work.

That approach won't work for the /bin folder though because IIS blocks script access in that folder. That can be overridden using the Request Filters that define that rule if I remember right, but it's messy because that has to be done at the IIS level (not the application/site level in web.config).

+++ Rick ---

The only issue with the approach I described (simply pointing the handler mapping to "Westwind.WebConnection.WebConnectionHandler") was the need to explicitly include "wconnect" in the urls. It actually looks like that may have a fairly simple solution.

I went into IIS on our test system and applied HTTP redirect with the following parameters:

With that in place, I can now hit my mapped pages both with and without the wconnect path:

https://www.testaceware.com/wconnect/about.awp

https://www.testaceware.com/about.awp

with the latter link automatically redirecting to the wconnect directory.

I don't really have any hard-coded references to wc.dll so that's not really an issue....

--stein

Stein -

You shouldn't need to do the redirection to WConnect - you just need to create your .awp script mapping in the website root ('Default Web Site' in this case).

As you have it set up, the .awp mapping is only established in the WConnect virtual (not the root), why is why the URL requires '/WConnect' to apply the .awp mapping.

Mike McDonald
Software Design of Kentucky

I'm not quite sure what you want to have happen. You're doing this because of legacy links in the /wconnect folder?

To me it would seem it's best to set up a site at the root rather than in /wconnect and run it from there. Shorter links and guaranteed no interference from a 'higher up' site. If the app doesn't have explicitly hardcoded links (ie. using relative links or ~/ links only) then moving between a virtual (/wconnect) and root (/) should be totally transparent. Web Connection can figure out base paths automatically based on the IIS mappings.

I realize this is probably not something you can 'just' do because you have a lot of installed applications, but if you do a redesign of the site setup, I think that should be a priority. The /wconnect folder was something that was needed in years back because IIS didn't make it easy to create new sites and manage host headers (especially for a development setup), but since IIS 7 that has become a lot easier to do. Plus recent versions of Web Connection are focusing on using IIS Express (or the .NET Core based server) which both run as a root Web site by default.

+++ Rick ---

Mike,

You shouldn't need to do the redirection to WConnect - you just need to create your .awp script mapping in the website root ('Default Web Site' in this case).

As you have it set up, the .awp mapping is only established in the WConnect virtual (not the root), why is why the URL requires '/WConnect' to apply the .awp mapping.

Actually that's not quite true depending on what handler you use. If you use the .NET handler the root site and the /wconnect site are two completely separate applications with separate address spaces. If you're running in COM and handle an .awp request in one it will start one set of COM servers, and if you then hit another request in /wconnect it'll start another set of COM servers.

One solution would be to not create a virtual for /wconnect and have all the configuration (ie. web.config) at the root site. That way the application lives in the root but can handle requests both in / and /wconnect - one problem with this is that the application base path will be only the site root, not /wconnect.

I think for Stein this would be an issue because there are probably path dependent dependencies on where to find templates and other application artifacts.

While not appropriate for Stein, it's a good way to go if you know up front you want to share resources in nested folders. It's one of the ways to get around the COM Servers per Application issue with the .NET Handler.

We in fact have tried running from the root folder under .NET and ran into the very issue Rick noted, with duplicate sets of COM servers being spawned. And yes, we have customers using hard coded absolute paths to /wconnect locations. (And as I noted, other customers will point to the same methods linked directly from the root.) So it really looks like running out of wconnect with the redirect in place is going to be the easiest way to migrate away from ISAPI.

After attending Rick's Deployment session at SWFox it's easy to see the advantages of using the newer design features. Whether it's worth the effort to implement them in a 20+ year old app with a large base of installed users is another question. Maybe down the road, but for now I'd just like to get them moved to .NET as quickly as possible.

--stein

Stein,

I would still be very careful with doing this as having two sites behaving like one can cause a lot of subtle little problems. Because essentially you have two sites that are using one set of shared objects.

Where this can bite you is with:

• Windows Authentication
• IIS generated Cookies
• Static file caching

Web Connection is less prone to problems with this because it uses its own internal authentication/cookie generation, but anything that is IIS managed - caching, Windows/Basic Authentication etc. is site specific and won't share across the root and /wconnect site.

It also means you have to make sure both folders stay in sync - you have to update both apps.

I would again suggest that you consolidate into a single site. Choose one or the other but not both.

+++ Rick ---

Now I'm confused. In my mind I already do have only one site - at the wconnect level. All I'm doing is forcing a redirect in those cases where the user invokes a url that omits the wconnect path. And generally that will only happen with the initial launching url; once they are navigating from within the app everything uses relative links so all links will include the wconnect path.

I don't see how this involves updating 2 apps or keeping folders in sync. The web.config with the handler mappings and the WC configuration settings exists only in the wconnect folder and there's just one copy of webconnectionhandler.dll in wconnect/bin and one copy of my .exe. What would I even sync with?

So far initial testing - simulating a typical user experience in Chrome, Edge and IE - has not triggered any issues...

--stein

Ok I misunderstood. I thought the issue was that there was both a root site and a /wconnect site.

+++ Rick ---