This is the same client that's having COM issues. As I reported, the app works in File Mode, but if we load the servers from the Module Admin page, it fails whenever we try to load a Web Control Framework page (and the app still uses several of those). The error is Class definition VBSCRIPT.REGEXP is not found generated by GetRegExObject in wwUtils - called from the WebPageParser object.

We can work around it if we log on to the server console and run the exe as Administrator. Is there a way to run VBSCRIPT.REGEXP without needing Admin privledges?

--stein

Since we seem to be stuck using File mode for the moment, I'd like to get this resolved. I'll admit don't understand how permissions work in this case - why is it necessary to run the exe as Admin in order to access the VBScript.Regexp? This is especially strange since the App Pool identity that's calling the exe is an Admin account.

Would it help to reregister vbscript.dll?

--stein

VBScript.RegEx is a COM object and it is part of the Windows Shell COM Components (very old). Those can be disabled by security policy and I wonder if that might be the case. If a machine is locked down for security there might be related issues to COM object usage and the shell objects might be part of that lockdown.

In theory it would be possible to replace all that VBScript.RegEx logic with using the .NET RegEx handler instead which would be more efficient anyway, but given this is in the WebControlFramework and old code that's not going to happen (and you're running an old version of WWWC anyway I'm betting).

Sorry but I don't have an answer to this - I tried to find out more but given that the tech around this is so old there's not much information coming up that's helpful. I do recall a long time ago in the ASP classic days that there were LOTS of problems with shell objects not working due to permissions with specific accound (notably IUSR) being disabled.

This might have to do (again) with impersnation - if the site uses pass through Impersonation, the Web site account (IUSR) wouldn't have rights to use the reg ex object.

+++ Rick ---

+++ Rick ---

...and you're running an old version of WWWC anyway I'm betting

You'd loose that one - we're on 7.06. I generally apply WC upgrades within a few weeks after you release them. I do include some nods to backwards compatibility such as #DEFINE WWC_PAGERESPONSE wwPageResponse40 But the usage in question is from webpageparser.PRG which hasn't changed since 2016.

I noticed that there is also a wwRegEx object defined in wwRegEx.prg - I looked into that thinking it would use newer tech and I could use it to update those calls, but it's just a wrapper with the VBSCRIPT object at its core. And it looks like wwRegEx is invoked in wwJSONserializer.PRG, so it's not just my outdated pages that still use the shell object. If you were to update wwRegEx to use the .NET regex handler, I would be happy to modify the webpageparser code to work with wwRegEx. (I think there are only like 4 instances where it makes direct calls to VBSCRIPT.RegEx object.)

--stein

Took a look at what it would take to switch to .NET Reg Ex instead of the VBScript one and it wouldn't be just a drop in replacement unfortunately. The objects returned by the VBRegEx object are quite different than the .NET objects and shimming would add too much overhead to make them work exactly the same. The only alternative then would be create a new class that's similar but different nevertheless.

Not sure if I have the energy to do this, especially given that the existing class works and I don't know why there's a problem in your particular environment from using the Shell objects.

+++ Rick ---

OK, just thought that might be a nice workaround if it was easy to implement. And you're right, the issue is just with this particular client - we're running the same app with WCF pages calling that same pageparser routine on dozens of other sites and AFAIK nobody has ever reported a problem with the RegExp object.

--stein