0

When I try to instantiate a VFP COM (OlePublic) DLL from my .NET web app running in IIS on Windows server 2016 I get:

Retrieving the COM class factory for component with CLSID {A55C4127-DDCB-4E5F-B69C-A7EAC83A83DC} failed due to the following error: 80004005 Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL)).

I was able to track it down (using Simon's comment) to it not being able to find vfp9r.dll:

failed to find vfp9r.dll screenshot from procmon

Those files got installed w/ my InstallShield package under C:\Program Files (x86)\Common Files\Microsoft Shared\VFP:

  • vfp9r.dll
  • VFP9RENU.dll
  • vfp9t.dll

screenshot of installshield package

Why isn't "it" searching that dir? I got one server it is finding them under program files and another that isn't. How does that magic work?

update

if I install VFP 9, it will search that dir & successfully load it. So what is the VFP 9 install doing to my machine to tell "it" to search that dir not just the current dir & \SysWow64?

search common dir screenshot

load image screenshot

spottedmahn
  • 14,823
  • 13
  • 108
  • 178
  • 2
    See https://github.com/VFPX/VFPRuntimeInstallers - `VfpX` is the semi-official community home since MS support ended – Stefan Wuebbe Oct 23 '22 at 21:43
  • 1
    That is access denied error. The account executing it do not have access to that folder? – Cetin Basoz Oct 24 '22 at 10:51
  • thanks @CetinBasoz, unfortunately I've learned that message happens for numerous reasons w/ these VFP com dlls. I did double check read permissions `common files` and the app pool has read rights. Also, I don't see it trying to read from that path in procmon. – spottedmahn Oct 24 '22 at 18:41
  • I have found in the past that if you rebuild a COM dll, many times the registry gets stupid on who has permissions and such. It has been as simple as going back into permissions and re-selecting the user account and possibly re-entering the password and it auto-magically works again. – DRapp Oct 24 '22 at 18:45

1 Answers1

0

workaround

import these registry keys:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\VisualFoxProRuntimeMT.9\Shell\Open\Command]
@="C:\\Program Files (x86)\\Common Files\\Microsoft Shared\\VFP\\vfp9t.dll"

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\VisualFoxProRuntime.9\Shell\Open\Command]
@="C:\\Program Files (x86)\\Common Files\\Microsoft Shared\\VFP\\vfp9r.dll"

(save the above 'script' as a .reg file and double click it to import it)

how I figured this out:

  • Hyper-V checkpoints so I could quickly go back and forth from a working to a non-working vm along w/ resetting after I did some test to find the minimal workaround
  • Search & export registry key w/ vfp9r.dll or vfp9t.dll
  • Compare exports via Notepad++ Compare Plus Plugin
  • The diff for vfp9t.dll was smaller so that was helpful. I grabbed the first key and that worked. Then I searched for the same-ish path for the vfp9r.dll export and grabbed that key.
spottedmahn
  • 14,823
  • 13
  • 108
  • 178