Hello!

We are migrating from 5.62 to 7.15 but we still use the old-styled requests using ~/wc.dll? ....

While these requests works ok with IIS and IIS Express we can't make it work through the local WebConnection Web Server. I tried to update the XML the following way without success:

<WebConnectionWebServerSettings xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <HandledExtensions>wc.dll,.wc,.wcs,.wwd,.md</HandledExtensions>
   ...
</WebConnectionWebServerSettings>

I couldn't find anywhere in docs a solution to this issue and would be very grateful for some help!

Kind Regards Dimitar Hristov

Yeah it won't work through the Web Connection Web server. You need to have a script map as that routes to the Web Connection server. You might be able to set the handled extension to .dll but I'm not sure if that will have the correct results when routing requests.

You really should re-configure you application to use script maps - it's much safer and more portable if you're running under IIS in production. If you're running in IIS you're stuck with the ISAPI extension which has been deprecated post 5.50. Still works but I'm not making changes to it and many of the cool admin improvements don't work with it. It's worth the minimal effort to switch to script maps.

How to switch:

• Search and Replace for wc.dll in HTML and Code
• Replace with wc.wc

Basically replace URLs like

\bin\wc.dll?process~method&parm1=x

to

\bin\wc.wc?process~method&parm1=x

You can play around with this before making the changes, but the behavior should be identical, except that now you can run in the .NET module or middleware and are not tied to ISAPI or the unsafe and restricted DLL extension.

That's all that should be needed to switch. Once that's done you're running on the .NET Module or .NET Core Middleware and you can at least use all the new features of the Web Connection administration and application management.

Once that's in place you can start migrating your URLS one at a time to use Method.ext?parm1=x rather than the old querystring syntax of wc.wc?process~method&parm1=x etc.

+++ Rick ---

Thanks for the prompt response, Rick.

I haven't payed attention that using ?wc.dll is actually non-sense for our case since we are already using the .NET managed ISAPI handler. So in our web.config we point "wc.dll" and ".wc" to same .NET handler which is quite odd but I guess its because of the v4.68 which was used for a while and when migrating to 5.62 the URLs were just retained (by applying the odd "wc.dll" handler in web.config). Basically it works just fine If I just change the url's to use /wc.wc?... instead (or any other non-existing .wc file). /Method.ext appear to work just fine as well - seems it was always being avilable but never used.

Also extensionless URLs work quite well using URL Rewrite IIS module and wwprocess::OnUrlRewrite method.

Have a good day! Dexter Hristov

Ideally eventually what you want, is get away from the funky wc.dll?process~method&parm1=x syntax and use Process.ext?parm1 instead.

Use of DLL is a potential flag for bots to try attack (a non-existant) ISAPI extension because in theory it's targeting a binary file. I think it'd also get flagged in a security audit. That's why even renaming to wc.wc is a good idea IMHO.

+++ Rick ---