Why doesn't .NET find the OpenSSL.NET dll?

EDIT (the whole question, it was too unclear)

The OpenSSL.NET install instructions page: INSTALL

Make sure you have libeay32.dll and ssleay32.dll in the current working directory of your application or in your PATH. DONE
In your .NET project, add a reference to the ManagedOpenSsl.dll assembly. DONE

I have put libeay32.dll and ssleay32.dll in both my bin/Debug and bin/Release directories. I have also put them in system32.

Here is my FULL code:

using System;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                OpenSSL.Crypto.RSA rsa = new OpenSSL.Crypto.RSA();
            }
            catch (Exception e)
            {
                Console.WriteLine(e.InnerException.Message);
            }
            Console.Read();
        }
    }
}

I get the following error: Unable to load DLL 'libeay32' http://localhostr.com/files/a719c5/Error.gif (Unable to load DLL 'libeay32')

Here is the Process Monitor log (upon request): alt text http://localhostr.com/files/726a46/ProcMon.gif

What am I doing wrong? Why isn't the DLL found?

Try the latest version of OpenSSL.NET (0.4.1) which should now include prebuilt libeay32.dll and ssleay32.dll binaries that link to the CRT statically. Alternatively, you can build these libraries yourself or use an 'official' build from openssl.org.

Without looking at your code exactly, I get that error when I:

do not have the dlls in the path of the executable (not where your sln resides, but where the .exe is made, typically in bin/debug or bin/x86/debug or whatever).
do not have the proper signature of the calling function (ie, I left out an integer parameter, the return types don't match, etc).
am not marshalling the types properly (ie, BOOL is marshalled as a bool, while bool is marshalled as a unsigned single byte integer, etc)-- while this last one may not cause the exception, it can cause decidedly funky behavior.
am on a 64 bit platform and am calling a 32 bit dll. The pointer sizes will be all different, and the dll will probably just crash and cause that exception.

EDIT: When all else fails, try dependency walker, because it sounds like your dlls are calling other dlls that aren't in your path or in the directory of the executable.

For anyone else out there still experiencing this issue (and have verified that the necessary prerequisites exist in their correct locations:

Check the OpenSSL.NET installation documentation and ensure its prerequisites are installed. In my case, a user was missing the Microsoft Visual C++ 2010 Redistributable Package (x86) dependency which is called out in the OpenSSL.NET documentation.

Cleiton

Your problem is related with this question:

DllNotFoundException, but DLL is there

Verify if all depencencies are in same folder of your application or are registred.

Try using probing. You need to create an XML config file named as the application's executable complete name (or named as the assembly that requieres your non-managed dll) with a .config extension. E.g. if your applications is name myapp.exe, the config file will be named myapp.exe.config The config file must be located in the same directory as the executable / assembly .

The config file is a simple xml file:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <runtime>
    <assemblyuBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="PATH" />
    </assemblyuBinding>
  </runtime>
</configuration>

Now the application will search in PATH when loading the assemblies. PATH is relative to the config /assembly file.

Not sure if it will work for non-managed dlls, but is worth the try.

The .NET way of doing this is to install your assembly in the global assembly cache.

Each computer where the common language runtime is installed has a machine-wide code cache called the global assembly cache. The global assembly cache stores assemblies specifically designated to be shared by several applications on the computer.

As a last resort, if nothing else works:

It may be useful to know where the application (.net or not) is looking for the DLLs. Just use Process Monitor and filter for the file name of the DLL. Then copy it to a location where the application is looking for it.

You're probably missing the VC++ redistributables. I'm assuming OpenSSL.NET is x86 only, so you can grab the VS2008 version x86 redistributable if they're release builds.

Otherwise, if they're debug builds (you'll see Microsoft.VC90.DebugCRT in EventViewer or the sxstrace logs) then you'll need to either:

Rebuild them as release
Install or copy the debug redistributables from another machine
Install Visual C++ into Visual Studio (or, probably, Visual C++ Express)

I found a solution.

Unfortunately the VS2008 C++ Redistributable package didn't work - I had to install the SP1 version AND VC++2008. The author said in a comment on its website that it was a mistake on its side, and not mine. He is currently recompiling the DLLs to be statically linked. Thank you to all of those who helped me :)

Try changing the Platform target for your project to x86 instead of "any cpu".

In my case, when we develop a web site with open ssl on x64 win 2008 platforms, we must check with application pool : allow 32 applications : true