¿Por qué .NET no encuentra la DLL de OpenSSL.NET?

Question

EDITAR (toda la cuestión, ya era demasiado claro)

Quiero usar OpenSSL.NET

El OpenSSL.NET instalar página de instrucciones: 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

he puesto libeay32.dll y ssleay32.dll en ambos mi bin/Debug y bin/Release directorios. También los puse en system32.

Aquí está mi código COMPLETO:

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(); 
     } 
    } 
} 

me sale el siguiente error: Unable to load DLL 'libeay32' http://localhostr.com/files/a719c5/Error.gif (No se puede cargar DLL 'libeay32')

Aquí está el registro de Monitor de procesos (a petición): alt text http://localhostr.com/files/726a46/ProcMon.gif

¿Qué estoy haciendo mal? ¿Por qué no se encuentra la DLL?

Answer 1

probar la última versión de OpenSSL.NET (0.4.1) que ahora debería incluir los archivos binarios prefabricados libeay32.dll y ssleay32.dll que enlazan al CRT de forma estática. Alternativamente, puede construir estas bibliotecas usted mismo o usar una compilación 'oficial' de openssl.org.

Answer 2

La manera .NET de hacer esto es instalar su ensamblaje en el 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.

Answer 3

Sin mirar a su código exactamente, me sale ese error cuando:

• no tienen los archivos DLL en la ruta del ejecutable (no donde reside su sln, pero donde el .exe está hecho, típicamente en bin/debug o bin/x86/debug o lo que sea).
• no tienen la firma adecuada de la función de llamada (es decir, dejé fuera un parámetro entero, los tipos de devolución no coinciden, etc.).
• no coordinando correctamente los tipos (es decir, BOOL se organiza como un bool, mientras que bool se clasifica como un entero de bytes único sin signo, etc.) - aunque este último no puede causar la excepción, puede causar un comportamiento decididamente funky .
• estoy en una plataforma de 64 bits y estoy llamando a un dll de 32 bits. Los tamaños del puntero serán todos diferentes, y el dll probablemente se bloqueará y causará esa excepción.

EDIT: Cuando todo lo demás falla, intente dependency walker, porque suena como archivos DLL están llamando a otros archivos DLL que no están en su camino o en el directorio del ejecutable.

Answer 4

Su problema está relacionado con esta pregunta:

DllNotFoundException, but DLL is there

comprobar si todos están en depencencies misma carpeta de su aplicación o son registradas.

Answer 5

Pruebe con el sondeo.Debe crear un archivo de configuración XML llamado nombre completo ejecutable de la aplicación (o nombrado como el ensamblado que requiere su dll no administrado) con una extensión .config. P.ej. si sus aplicaciones tienen el nombre myapp.exe, el archivo de configuración se llamará myapp.exe.config El archivo de configuración debe estar ubicado en el mismo directorio que el ejecutable/ensamblado.

El archivo de configuración es un archivo XML simple:

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

Ahora, la aplicación buscará en el PATH al cargar las asambleas. PATH es relativo al archivo config/assembly.

No estoy seguro si funcionará para dlls no administrados, pero vale la pena intentarlo.

Answer 6

Como último recurso, si nada más funciona:

Puede ser útil saber dónde está la aplicación (.NET o no) está buscando los archivos DLL. Simplemente use Process Monitor y filtre para el nombre de archivo de la DLL. Luego, cópielo en una ubicación donde la aplicación lo esté buscando.

Answer 7

Probablemente te faltan los redistribuibles de VC++. Supongo que OpenSSL.NET es solo x86, por lo que puede grab the VS2008 version x86 redistributable si se trata de compilaciones de versiones.

De lo contrario, si son versiones de depuración (verá Microsoft.VC90.DebugCRT en EventViewer o los registros sxstrace), entonces usted tendrá que o bien:

• reconstruirlos como la liberación
• instalar o copiar los redistributables depuración de otra máquina
• instalar Visual C++ en Visual Studio (o, probablemente, Visual C++ Express)

Answer 8

Encontré una solución.

Lamentablemente, el paquete VS2008 C++ redistribuible no funcionó: tuve que instalar la versión SP1 Y VC++ 2008. El autor dijo en un comentario en su sitio web que fue un error de su parte, y no mío. Actualmente está recompilando los archivos DLL para que estén vinculados estáticamente. Gracias a todos los que me ayudaron :)

Answer 9

Intente cambiar el objetivo de la plataforma para su proyecto a x86 en lugar de "cualquier CPU".

Answer 10

Para cualquier otra persona por ahí sigue experimentando este problema (y han comprobado que existen las condiciones que deben cumplirse en su ubicación correcta:.

Compruebe el OpenSSL.NET installation documentation y asegurar que se instalan los requisitos previos En mi caso, un usuario era falta la dependencia Microsoft Visual C++ 2010 Redistributable Package (x86) que se menciona en la documentación de OpenSSL.NET.

Answer 11

En mi caso, cuando desarrollamos un sitio web con SSL abierta en x64 ganar plataformas de 2008, hay que consultar con el grupo de aplicaciones: permitir que 32 aplicaciones: verdadera