libeay32.dll not found

Hello,

I’ve been trying to test our build that should publish messages to a solace server. And subscribe to queues. This build seems to work on any other machine. But the test servers keep failing on every connection attempt to solace. We see the same error can’t find libeay32.dll.

I have made builds for AnyCpu, 64x and 86x. The error is consistent.

Note we are using version 10.5.0.0. We are on .Net Framework 4.8

Also note that downloading openssl 64x and replacing the libeay32.dll and ssleay32.dll fixes the issue. But this is not a solution for our continuous deployment. We are wondering what suggestions you may have.

Can you provide any insight into the differences between the machines that work (i.e. assuming they are windows desktops) and the test servers (assume they are windows server machines)?

The servers where it doesn’t work are Windows server 2016 Standard (version 1607) edition and works fine on Windows 10/11 Enterprise editions (version 22H2).

A coworker gave me the solution. We needed to install SQLSysCLRTypes. This package seems to include some dependencies that are needed.

Thank you for letting us know you figured it out!

Actually that didn’t solved it. I thought it did but was the dlls downloaded from openssl that were still working. After doing a fresh install the issue still there.

@marc.dipasquale , @RobO actually that didn’t work. Our solace server is on version 9.8 and 10.4. I have been updating the solace nuget package from 10.5 to 10.10 and looks like the issue is still happening. Looking at the dlls from the solace nuget package for libcrypto they are on 1.1.1c while I was reading (here)[

] that on Windows Server 2016 they don’t work and they need to be version 1.1.1d to work. Same as my initial error.

Not sure if you know about this issue, and if there is a solution for this?

Hi @alberto ,

I believe the solution here is to provide your own SSL libraries as part of your build and add them tot he LD_LIBRARY_PATH. The API will load the TLS libraries found on LD_LIBRARY_PATH first and only resort to loading the libraries co-located with libsolclient.so as a backup.

Note from docs in supported environment:

Note that this was recently discussed in a github issue as well that has some more context:

Hope that helps!