1
votes

I have to call a REST API. I first wrote a standard Delphi VCL Forms Application to test calling the API and it worked 100%. I then moved the code into my COM+ application. I compiled the DLL and registered it in Component Services (as per normal). I set the break-point in my DLL and ran it - while DLL is running I started my HOST application that allowed me to debug my DLL. When I run it with the DLL in debug mode, everything is still working 100%.

The problem is that when the DLL is not running in debug mode, but I run the HOST application (stand alone or from IDE), I get a "Could not load SSL Library" error when trying to call the REST API. Both the libeay32.dll and ssleay32.dll files are in the same directory as my DLLs. I doubled check my component services and that is also pointing to the same directory.

Question: Where do I need to put the libeay32.dll and ssleay32.dll files in order for my COM+ DLL to see and load them?

The irony is that I cannot debug because then it works. I have tried WhichFailedToLoad() but that gives me an access violation.

1
for debug purposes - try write to log (or show) CurrentDirectory when call REST functions. Possibly "The directory from which the application loaded"is not same as Hostapp for your dll ( docs.microsoft.com/ru-ru/windows/win32/dlls/… ) - kami
Try analyzing with procmon to see where it is trying to search for the dll's or more advanced enable loader snaps and watch the debug output - Remko
@kami, I had the same idea. When I ran in debug my GetCurrentDir points to the DLL directory i.e. E:\PMO\Bin, but when I run outside debug, the GetCurrentDir points to C:\Windows\System32. I've copied the 2 SSL DLLs to the latter but unfortunately it did not make a difference. - Johan
@Johan on a 64bit system the 32bit DLLs need to go in SysWow64. - Brian
@Johan "I've copied the 2 SSL DLLs to the latter" - don't do that, non-system files do not belong in system folders. Indy has an IdOpenSSLSetLibPath() function so you can tell Indy to load the OpenSSL DLLs using absolute paths in a specific folder. And Windows has SetDllDirectory() and AddDllDirectory() functions to add additional search paths when loading DLLs by relative paths (what Indy does by default). Use one of those approaches instead. Your DLL can retrieve its own path at runtime and then update Indy/Windows accordingly before Indy loads the OpenSSL DLLs. - Remy Lebeau

1 Answers

1
votes

@Remko, thanks for pointing me to ProcMon, not the most user-friendly app but it did the job. I couldn't find a reference to the SSL libraries but I did noticed that my application was accessing DLLs in the C:\Windows\SysWow64 directory. I copied the SSL DLLs to that directory and, Bob's your uncle, it worked!

@Brian, thanks for the reply. You are correct, that was the issue.