A: 

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.

Andrew Hare
Isn't there any simpler way? Considering I will share my binaries, this isn't quite useful.
Lazlo
Considering you're not familiar with .NET, I suggest "when in Rome, do as the Romans do".
John Saunders
+1  A: 

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.

mmr
I have the Dlls in the .exe's path, and the function is right.
Lazlo
To your edit: I am sure the types are properly used. I am only initializing the API using the default code.And I am running a 32-bit machine with 32-bit dlls.
Lazlo
Dependency walker, then, as I added in. It's probably going to show you that you're missing something.
mmr
No, the dll I'm missing is libeay32.dll, which I have and is in both in the system32 and the exe folder.
Lazlo
Right, but you can get that dllnotfound exception when libeay32.dll calls some other dll. Dependency walker will show you what's missing, if anything.
mmr
Please re-read the question, I have edited it. You will notice that libeay32.dll is not found, not one of its dependencies.
Lazlo
Ah, a side-by-side configuration error is different. What was openssl compiled with, and what compiler are you using? Do you have the most recent service packs for your compiler and for .NET?
mmr
I only started getting side-by-side errors when I was on Vista or Windows 7, never on XP. Which OS are you developing on?
mmr
+1  A: 

Your problem is related with this question:

http://stackoverflow.com/questions/1246486/dllnotfoundexception-but-dll-is-there/1246501#1246501

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

Cleiton
I did. Still doesn't work. Re-read the edit please, if you haven't.
Lazlo
+1  A: 

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.

Ricky AH
A: 

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.

Peter Hahndorf
Here is the procmon log:http://localhostr.com/files/726a46/ProcMon.gif
Lazlo
A: 

I have completely re-edited the question for it to be simpler. Please re-read it.

Lazlo
A: 

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)
Mark Brackett
+2  A: 

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.

fried
It was a bug on OpenSSL.NET's part. :)
Lazlo
A: 

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 :)

Lazlo
A: 

Even with the 0.4.1 version, I'm still getting this, even if I'm just trying to run the test application:

Unhandled Exception: System.TypeInitializationException: The type initializer for 'OpenSSL.Core.Native' threw an exception. ---> System.DllNotFoundException: Unable to load DLL 'libeay32': This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1) at OpenSSL.Core.Native.SSLeay() at OpenSSL.Core.Version.getLibrary() at OpenSSL.Core.Native..cctor() --- End of inner exception stack trace --- at OpenSSL.Core.Native.CRYPTOmallocdebuginit() at OpenSSL.Core.MemoryTracker.Start() at test.Program.Run(String[] args) at test.Program.Main(String[] args)

I can confirm that the app is loading the DLLs that I put in the same directory, because if I remove them and replace them with other versions (from a different app, say Apache) I get a different error ("no such entry point CRYPTOmallocdebuginit()"). So it's not having issues finding them directly, per se. Any other suggestions?

andersop
A: 

I am getting the same error on a Win32 machine, odd that this wrapper appears to be written for Win32 (named openssl-net.0.4.1-win32.zip), even after installing the VS2008C++ redistributable. I ran dependency walker on it and found that DWMAPI.DLL is missing. Has anyone ran into this? Seems like I have seen this error before but I can't recall how or if there is a fix for it. I do have all the latest updates and patches. Thanks for your help.

If I run DependencyWalker on the ManagedOpenSSL.dll, DWMAPI.DLL doesn't even appear in the list - but it does complain that MSJAVA.DLL is missing. Huh?
andersop
A: 

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

rvo