Perché .NET non trova la dll di OpenSSL.NET?

Question

EDIT (tutta la questione, era troppo chiaro)

voglio usare OpenSSL.NET

L'OpenSSL.NET installare pagina di istruzioni: 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

ho messo libeay32.dll e ssleay32.dll in entrambi i miei bin/Debug e bin/Release directory. Li ho anche inseriti in system32.

Ecco il mio codice 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(); 
     } 
    } 
} 

ottengo il seguente errore: Unable to load DLL 'libeay32' http://localhostr.com/files/a719c5/Error.gif (Impossibile caricare la DLL 'libeay32')

Ecco il registro Process Monitor (su richiesta): alt text http://localhostr.com/files/726a46/ProcMon.gif

Cosa sto sbagliando? Perché la DLL non è stata trovata?

Answer 1

provare l'ultima versione di OpenSSL.NET (0.4.1) che ora dovrebbe includere i binari libeay32.dll e ssleay32.dll precostituiti che si collegano al CRT in modo statico. In alternativa, puoi creare queste librerie da solo o usare una build 'ufficiale' da openssl.org.

Answer 2

Il modo .NET di eseguire questa operazione è installare l'assembly nel 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

Senza guardare il codice esattamente, ottengo questo errore quando:

• non hanno le DLL nel percorso del file eseguibile (non dove i vostri risiede SLN, ma dove l'exe è fatto, tipicamente in bin/debug o bin/x86/debug o qualsiasi altra cosa).
• non hanno la firma corretta della funzione chiamante (cioè, ho omesso un parametro intero, i tipi restituiti non corrispondono, ecc.).
• am non esegue correttamente il marshalling dei tipi (ad esempio, BOOL viene eseguito il marshalling come bool, mentre bool è marshalling come numero intero di byte singolo senza segno, ecc.) - mentre quest'ultimo non può causare l'eccezione, può causare un comportamento decisamente funky .
• su una piattaforma a 64 bit e sto chiamando una dll a 32 bit. Le dimensioni del puntatore saranno tutte diverse e probabilmente la dll si bloccherà e causerà quell'eccezione.

EDIT: Quando tutto il resto fallisce, provare dependency walker, perché suona come le DLL chiamano altre DLL che non sono nel vostro percorso o nella directory del file eseguibile.

Answer 4

Il tuo problema è correlato con questa domanda:

DllNotFoundException, but DLL is there

Verificare se tutti i depencencies sono in stessa cartella dell'applicazione o sono registrato.

Answer 5

Provare a utilizzare il rilevamento.È necessario creare un file di configurazione XML denominato nome completo eseguibile dell'applicazione (o denominato come assembly che richiede la DLL non gestita) con un'estensione .config. Per esempio. se le applicazioni sono denominate myapp.exe, il file di configurazione sarà denominato myapp.exe.config Il file di configurazione deve trovarsi nella stessa directory dell'eseguibile/assembly.

Il file di configurazione è un semplice file XML:

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

Adesso l'applicazione cercherà in PATH durante il caricamento delle assemblee. PATH è relativo al file config/assembly.

Non so se funzionerà con le DLL non gestite, ma vale la pena provarlo.

Answer 6

Come ultima risorsa, se non altro funziona:

Può essere utile sapere dove l'applicazione (.net o meno) è alla ricerca di DLL. Basta usare Process Monitor e filtrare il nome del file della DLL. Quindi copiarlo in una posizione in cui l'applicazione lo sta cercando.

Answer 7

Probabilmente mancano i ridistribuibili VC++. Suppongo che OpenSSL.NET sia solo x86, quindi puoi grab the VS2008 version x86 redistributable se sono versioni di rilascio.

In caso contrario, se sono build di debug (vedrete Microsoft.VC90.DebugCRT in EventViewer o registri sxstrace), allora avrete bisogno di uno:

• a ricostruire come il rilascio
• installare o copiare i ridistribuibili di debug da un'altra macchina
• installare Visual C++ in Visual Studio (o, probabilmente, Visual C++ espresso)

Answer 8

Ho trovato una soluzione.

Sfortunatamente il pacchetto ridistribuibile C++ VS2008 non ha funzionato - ho dovuto installare la versione SP1 AND VC++ 2008. L'autore ha detto in un commento sul suo sito web che è stato un errore dalla sua parte, e non il mio. Attualmente sta ricompilando le DLL per essere collegate staticamente. Grazie a tutti quelli che mi hanno aiutato :)

Answer 9

Provare a cambiare l'obiettivo della piattaforma per il progetto su x86 invece di "qualsiasi CPU".

Answer 10

Per chiunque altro là fuori ancora sperimentando questo problema (ed hanno verificato che i prerequisiti necessari esistono nelle loro posizioni corrette:.

Controllare la OpenSSL.NET installation documentation e garantire la sua prerequisiti siano installati Nel mio caso, un utente è stato manca la dipendenza Microsoft Visual C++ 2010 Redistributable Package (x86) che viene richiamata nella documentazione di OpenSSL.NET.

Answer 11

Nel mio caso, quando sviluppiamo un sito web con SSL aperta su x64 vincere 2008 piattaforme, dobbiamo controllare con pool di applicazioni: consentire 32 applicazioni: vero