2009-08-07 10 views
25

Quindi sto utilizzando un SDK per un generatore di numeri casuali hardware che fornisce una DLL chiamata PsyREG.dll per l'interazione con esso, così come qualche fonte C# per l'utilizzo dei metodi dalla dll.DllNotFoundException, ma DLL è lì

Ha funzionato in passato, ma in qualche modo ha smesso di funzionare. Le mie mani sono un po 'legate perché al momento non ho accesso al dispositivo in questione, quindi non posso provare un sacco di cose ...

Tuttavia, ecco la cosa strana. La dll è lì, lo stesso posto è sempre stato. Ahd infatti File.Exists ("PsyREG.dll") restituisce true, e ho ricontrollato e questo è esattamente lo stesso modo in cui il sorgente C# fornito lo importa, ad es. [DllImport ("PsyREG.dll")].

Qualche idea?

risposta

34

Probabilmente questa DLL ha alcune dipendenze che non sono registrate o non sono nella stessa cartella della vostra applicazione.

+0

Grazie, che è stato. C'erano alcune altre cose che erano necessarie, ma per alcuni motivi non pensavo di verificarlo (incluso il fatto che diceva che non poteva caricare PsyREG.dll, non un file diverso) – Asmor

+1

Tempi come questo sono quando io scoppiare Riflettore. Può mostrarti le dipendenze. In particolare, può mostrarti quali non sono stati trovati. –

+0

Davvero? Reflector trova le dipendenze non gestite? Dov'è questa opzione? – erikkallen

1

Forse dovresti controllare se stai aspettando una versione specifica del prodotto della DLL e assicurarti che le versioni del prodotto corrispondano ancora correttamente.

4

Aprire DLL sul sistema problematico in http://www.dependencywalker.com/

+0

Questa app ha fatto il lavoro per me. –

+0

cool ... questo strumento mi ha aiutato a risolvere molti problemi di installazione durante la distribuzione. – cbuteau

0

avevo a che fare con la stessa eccezione per quanto riguarda uno dei miei DLL (chiamiamolo A). C# si bloccava perché affermava che non riusciva a trovare questa DLL (A) (mentre era lì nella stessa cartella dell'eseguibile).

Si è scoperto che il problema era causato da A con dipendenza da un'altra DLL (chiamarla B). B non era nel percorso in modo che A non potesse caricarlo quando necessario. Poiché B aveva bisogno di un sacco di altre DLL, la soluzione era aggiungere la directory B alla variabile di ambiente PATH.

E 'interessante come C# si blocca con l'errore dicendo che A non si trova, quando in realtà B non è stato trovato ...

+0

Puoi spiegare 'la soluzione era aggiungere la directory di B alla parte della variabile di ambiente del percorso' un po '? Attualmente sto combattendo con lo stesso problema, l'unica differenza è che la mia Dll vuole alcuni file * .so invece di altri Dll. – Stefan

+0

@Stefan Credo che nel terminale di Linux si debba fare 'export PATH = $ PATH: YOUR-SO-FILE-PATH' per aggiungere la directory 'YOUR-SO-FILE-PATH' alla variabile d'ambiente PATH. In questo modo, quando il file 'so' deve essere caricato, il percorso specificato da PATH verrà cercato per trovare il file' so'. – M2X

+0

Grazie, l'ho provato in questo modo ma non ha funzionato davvero. Ho letto da qualche altra parte per spostare la mia DLL nella directory '/ usr/lib' (sì, è davvero un sistema linux) e questo ha funzionato senza alcuna ulteriore configurazione – Stefan

0

mi sono imbattuto in questo problema e risolto con il seguente:

C'è una dipendenza su msvcr90.dll se si compila sotto/MD. Prova a compilare il codice con/MT.

Project properties>C/C++>Code Generation>Runtime Library: /MT

Problemi correlati