2009-08-07 13 views
25

Also ich benutze ein SDK für eine Hardware-Zufallsgenerator, der eine DLL namens PsyREG.dll für die Interaktion mit ihm, sowie einige C# Quelle für die Verwendung der Methoden aus der DLL zur Verfügung stellt.DllNotFoundException, aber DLL ist da

Es hat in der Vergangenheit funktioniert, aber irgendwie funktioniert es nicht mehr. Meine Hände sind ein bisschen gefesselt, da ich momentan keinen Zugang zu dem fraglichen Gerät habe, also kann ich nicht viele Dinge ausprobieren ...

Aber hier ist das komische Ding. Die DLL ist da, derselbe Ort, an dem es schon immer war. Ahd in der Tat File.Exists ("PsyREG.dll") gibt true zurück, und ich habe es doppelt überprüft und das ist genau die gleiche Art, wie die bereitgestellte C# -Quelle es importiert, z. [DllImport ("PsyREG.dll")].

Irgendwelche Ideen?

Antwort

34

Es ist wahrscheinlich diese DLL hat einige Abhängigkeiten, dass sie nicht registriert sind oder nicht im selben Ordner Ihrer Anwendung.

+0

Danke, das war es. Es gab einige andere Dinge, die benötigt wurden, aber aus ein paar Gründen dachte ich nicht, das zu überprüfen (einschließlich der Tatsache, dass es sagte, dass es PsyREG.dll, keine andere Datei laden konnte) – Asmor

+1

Zeiten wie das sind, wenn ich Reflektor ausbrechen. Es kann Ihnen die Abhängigkeiten zeigen. Insbesondere kann es Ihnen zeigen, welche nicht gefunden werden. –

+0

Wirklich? Finden Reflector nicht verwaltete Abhängigkeiten? Wo ist diese Option? – erikkallen

1

Vielleicht sollten Sie prüfen, ob Sie eine bestimmte Produktversion der DLL erwarten, und sicherstellen, dass die Produktversionen immer noch korrekt übereinstimmen.

4

Öffnen DLL auf dem problematischen System in http://www.dependencywalker.com/

+0

Diese App hat den Job für mich erledigt. –

+0

cool ... dieses Tool hat mir geholfen, viele Installationsprobleme beim Deployment zu lösen. – cbuteau

0

Ich war in Bezug auf eine meiner DLL mit der gleichen Ausnahme zu tun (nennen wir es A). C# stürzte ab, weil es behauptete, dass es diese DLL nicht finden konnte (A) (während es dort im selben Ordner wie die ausführbare Datei war).

Es stellte sich heraus, dass das Problem von A verursacht wurde, die Abhängigkeit von einer anderen DLL (nennen Sie es B). B war nicht im Pfad, so A konnte es nicht laden, wenn es benötigt wurde. Da B eine ganze Reihe anderer DLLs benötigte, bestand die Lösung darin, das Verzeichnis B der Umgebungsvariablen PATH hinzuzufügen.

Es ist interessant, wie C# Abstürze mit der Fehlermeldung, dass A nicht gefunden wird, wenn in der Tat B nicht gefunden wurde ...

+0

Kannst du erklären, dass 'die Lösung darin bestand, B's Verzeichnis dem Pfad-Umgebungsvariablen-Teil ein wenig hinzuzufügen? Ich streite gerade mit fast dem gleichen Problem, nur Unterschied ist, dass meine Dll einige * .so Dateien anstelle von anderen Dlls will. – Stefan

+0

@Stefan Ich glaube an Linux-Terminal, Sie würden 'PATH = $ PATH: YOUR-SO-FILE-PATH' exportieren, um das Verzeichnis' YOUR-SO-FILE-PATH' zu Ihrer PATH-Umgebungsvariablen hinzuzufügen. Auf diese Weise wird, wenn Ihre 'so'-Datei geladen werden muss, der durch PATH angegebene Pfad durchsucht, um diese' so' Datei zu finden. – M2X

+0

Danke, ich habe es auf diese Weise versucht, aber es hat nicht wirklich funktioniert. Ich habe irgendwo anders gelesen, um meine DLL in das '/ usr/lib'-Verzeichnis zu verschieben (ja, es ist in der Tat ein Linux-System) und das funktionierte ohne weitere Konfiguration – Stefan

0

ich in dieses Problem lief und mit der folgenden gelöst:

Es gibt eine Abhängigkeit auf msvcr90.dll, wenn Sie unter/MD kompilieren. Versuchen Sie stattdessen, den Code mit/MT zu kompilieren.

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