wake-up-neo.com

Unfähig zu laden DLL (Modul konnte nicht gefunden werden HRESULT: 0x8007007E)

Ich habe DLL-Bibliothek mit nicht verwaltetem C++ API-Code, den ich in meiner .NET 4.0-Anwendung verwenden muss. Aber jede Methode, die ich versuche, meine DLL zu laden, erhalte ich eine Fehlermeldung: 

DLL 'MyOwn.dll' kann nicht geladen werden: Das angegebene Modul wurde nicht gefunden. (Ausnahme von HRESULT: 0x8007007E)

Ich habe im Internet gefundene severa-Lösungen gelesen und ausprobiert. Nichts funktioniert.. 

Ich habe folgende Methoden ausprobiert:

[DllImport("MyOwn.dll",  CallingConvention = CallingConvention.Cdecl)]
[return: MarshalAs((UnmanagedType.I4))]
public static extern Int32 MyProIni(string DBname, string DBuser_pass,
    string WorkDirectory, ref StringBuilder ErrorMessage);

Wenn ich versucht habe, diesem Artikel zu folgen und dieses Beispiel (aus dem heruntergeladenen Code) auszuführen, wird es ohne Probleme ausgeführt (die verwendete DLL befindet sich im Ordner bin/debug).

Ich habe meine DLL (zusammen mit allen Dateien, von denen es abhängt, in meinen Ordner "Bin" kopiert).

Ich habe auch diesen Ansatz ausprobiert, aber den gleichen Fehler erhalten:

[DllImportAttribute(MyOwnLibDllPath, EntryPoint="TMproIni")]
[return: MarshalAs(UnmanagedType.I4)]
public static extern  int MyproIni(string DBname, string DBuser_pass, 
    string WorkDirectory, ref StringBuilder ErrorMessage);

Irgendwelche Vorschläge?

89

Von dem, an den ich mich unter Windows erinnere, ist die Suchreihenfolge für eine DLL:

  1. Aktuelles Verzeichnis
  2. Systemordner C:\windows\system32 or c:\windows\SysWOW64 (für einen 32-Bit-Prozess in einer 64-Bit-Box).
  3. Lesen aus der Umgebungsvariablen Path

Außerdem würde ich die Abhängigkeiten der DLL überprüfen. Der mit Visual Studio mitgelieferte Dependency Walker kann Ihnen hier helfen, er kann auch kostenlos heruntergeladen werden: http://www.dependencywalker.com

83
display101

Sie können das dumpbin-Tool verwenden, um die erforderlichen Abhängigkeiten von DLL herauszufinden:

dumpbin /DEPENDENTS my.dll

Dadurch erfahren Sie, welche DLLs Ihre DLL laden muss. Achten Sie besonders auf MSVCR * .dll. Ich habe gesehen, dass Ihr Fehlercode auftritt, wenn die korrekte Visual C++ Redistributable nicht installiert ist.

Sie können die "Visual C++ Redistributable Packages für Visual Studio 2013" von der Microsoft-Website herunterladen. Es installiert c:\windows\system32\MSVCR120.dll

Im Dateinamen ist 120 = 12.0 = Visual Studio 2013.

Achten Sie darauf, dass Sie über die richtige Visual Studio-Version (10.0 = VS 10, 11 = VS 2012, 12.0 = VS 2013 ...) und die richtige Architektur (x64 oder x86) für die Zielplattform Ihrer DLL verfügen Debug-Builds. Der Debug-Build einer DLL hängt von MSVCR120d.dll ab. Hierbei handelt es sich um eine Debugversion der Bibliothek, die mit Visual Studio installiert wird, nicht jedoch mit dem Redistributable Package.

31
Anthony Hayward

Die DLL muss sich im Ordner bin befinden.

In Visual Studio füge ich meinem Projekt die DLL hinzu (NICHT in Verweise, sondern "Vorhandene Datei hinzufügen"). Setzen Sie anschließend die Eigenschaft "Copy to Output Directory" für die DLL auf "Copy if newer".

10
Jeremy Thompson

Versuchen Sie, den vollständigen Pfad der DLL einzugeben. Wenn dies nicht funktioniert, kopieren Sie die DLL in den system32-Ordner.

10
Headpuster

Stellen Sie sicher, dass alle Abhängigkeiten Ihrer eigenen DLL in der Nähe der DLL oder in System32 vorhanden sind.

4
Felice Pollano

Dies ist ein 'kludge' aber Sie könnten es zumindest für den folgenden Test verwenden: Versuchen Sie, den Pfad zur DLL in Ihrem Code fest zu codieren

[DllImport(@"C:\\mycompany\\MyDLL.dll")]

Das gesagt haben; In meinem Fall lief dumpbin /DEPENDENTS, wie von @ anthony-hayward vorgeschlagen, und das Kopieren von 32-Bit - Versionen der dort aufgelisteten DLLs in mein Arbeitsverzeichnis löste dieses Problem für mich.

Die Nachricht ist nur ein wenig irreführend, da es sich nicht um "meine" DLL handelt, die nicht geladen werden kann, sondern um die Abhängigkeiten

4
Black

Es gibt eine sehr lustige Sache (und hat eine technische Relevanz), die Ihre Stunden verschwenden könnte.

Ich habe ein Konsolenanwendungsprojekt ConsoleApplication1 und ein Klassenbibliothekprojekt ClassLibrary1 erstellt.

Der gesamte Code, aus dem p/invoke gemacht wurde, war in ClassLibrary1.dll vorhanden. Vor dem Debuggen der Anwendung aus Visual Studio habe ich einfach die nicht verwaltete C++ - Assembly (myUnmanagedFunctions.dll) in das Verzeichnis \bin\debug\ des ClassLibrary1-Projekts kopiert, damit sie zur Laufzeit von der CLR geladen werden kann. 

Ich habe immer das bekommen 

DLL kann nicht geladen werden

fehler für Stunden. Später erkannte ich, dass alle nicht verwalteten Assemblys, die geladen werden sollen, in das Verzeichnis \bin\debug des Startprojekts ConsoleApplication1 kopiert werden müssen. Hierbei handelt es sich normalerweise um ein Win-Formular, eine Konsole oder eine Webanwendung.

Seien Sie also vorsichtig, denn der Current Directory in der akzeptierten Antwort bedeutet Current Directory der ausführbaren Hauptdatei, von der aus Ihr Anwendungsprozess gestartet wird. Sieht aus wie eine offensichtliche Sache, kann aber manchmal nicht so sein.

Lesson Learned - Platzieren Sie die unmanagierten DLLs immer in demselben Verzeichnis wie die Startdatei, um sicherzustellen, dass sie gefunden wird.

4
RBT

Schalten Sie die Fusionsprotokollierung ein, siehe diese Frage , um Ratschläge zu erhalten. Das Beheben von Problemen beim Laden von Mischmodus-Apps kann ein recht königlicher Schmerz sein. Die Fusionsprotokollierung kann eine große Hilfe sein.

3
Chris O

Ich hatte das gleiche Problem, als ich meine Anwendung zum Testen eines PCs bereitstellte. Das Problem war, dass der Entwicklungs-PC msvcp110d.dll und msvcr110d.dll hatte, aber nicht der Test-PC. 

Ich habe in InstalledSheild das Merge-Modul "Visual Studio C++ 11.0 DebugCRT (x86)" hinzugefügt und es hat funktioniert. Hoffe, das wird für jemand anderen hilfreich sein.

2
kakopappa

Wenn sich das DLL - und das .NET-Projekt in derselben Projektmappe befinden und Sie jedes Mal beide kompilieren und ausführen möchten, können Sie mit der rechten Maustaste auf die Eigenschaften des .NET-Projekts "Ereignisse erstellen" klicken und anschließend Folgendes hinzufügen Befehlszeile nach dem Build-Ereignis:

copy $(SolutionDir)Debug\MyOwn.dll .

Es handelt sich im Grunde um eine DOS-Zeile, und Sie können Tweak basierend darauf ändern, wo Ihre DLL erstellt wird.

2
SharpC

Stellen Sie sicher, dass Sie das Build Platform Target auf x86 oder x64 setzen, damit es mit Ihrer DLL kompatibel ist - die möglicherweise für eine 32-Bit-Plattform kompiliert wird.

2
Grantly

Setup: 32-Bit-Windows 7

Context: Es wurde ein PCI-GPIB-Treiber installiert, über den ich aufgrund des oben genannten Problems nicht kommunizieren konnte.

Kurze Antwort: Treiber neu installieren.

Lange Antwort: Ich habe auch Dependency Walker verwendet, wodurch mehrere fehlende Abhängigkeitsmodule identifiziert wurden. Ich dachte sofort, dass es eine verpatzte Treiberinstallation gewesen sein muss. Ich wollte nicht jede fehlende Datei überprüfen und wiederherstellen.

Die Tatsache, dass ich das Deinstallationsprogramm unter Programme und Funktionen der Systemsteuerung nicht finden konnte, ist ein weiterer Indikator für eine fehlerhafte Installation. Ich musste ein paar * .dll in\system32 und die Registrierungsschlüssel manuell löschen, um die Neuinstallation des Treibers zu ermöglichen.

Problem behoben.

Der unerwartete Teil war, dass nicht alle Abhängigkeitsmodule aufgelöst wurden. Trotzdem kann jetzt auf die interessierende * .dll verwiesen werden.

1
icernos

Ich bin auf das gleiche Problem gestoßen. In meinem Fall hatte ich zwei 32-Bit-PCs. Eines mit .NET4.5 und ein anderes war ein neuer PC.

meine 32-Bit-cpp-dll (Release-Modus-Build) funktionierte gut mit einem auf .NET installierten PC, aber nicht mit einem frischen PC, bei dem ich den unten stehenden Fehler erhielt

DLL 'PrinterSettings.dll' kann nicht geladen werden: Das angegebene Modul konnte nicht .__ sein. gefunden (Ausnahme von HRESULT: 0x8007007E)

endlich, 

Ich habe gerade mein Projekt in Debug-Modus -Konfiguration und diesmal mein. cpp dll funktionierte gut.

1
Abu Muhammad

In meinem Fall war eine nicht verwaltete DLL von einer anderen abhängig, die fehlte. In diesem Fall verweist der Fehler auf die vorhandene DLL und nicht auf die fehlende, was sehr verwirrend sein kann.

Genau das war in meinem Fall passiert. Hoffe das hilft jemand anderem.

0
Rahatur

Ich denke, Ihre nicht verwaltete Bibliothek benötigt ein Manifest.
Hier wird es zu Ihrer Binärdatei hinzugefügt. und hier warum.

Zusammenfassend können mehrere Redistributable-Bibliotheksversionen in Ihrer Box installiert werden, aber nur eine davon sollte Ihrer App genügen, und es ist möglicherweise nicht die Standardeinstellung. Daher müssen Sie dem System die Version mitteilen, die Ihre Bibliothek benötigt, daher das Manifest.

0
Eugenio Miró

Das gleiche Problem trat auch bei der Verwendung einer nicht verwalteten c/c ++ - DLL-Datei in der c # -Umgebung auf.

1.Überprüfung der Kompatibilität von DLL mit 32-Bit- oder 64-Bit-CPU.

2.Überprüfen Sie die korrekten Pfade des DLL .bin-Ordners, system32/sysWOW64 oder des angegebenen Pfads.

3.Überprüfen, ob PDB-Dateien (Programmdatenbanken) fehlen. Dieses video gibt Ihnen die beste und über pdb-Dateien stehen.

Bei der Ausführung von 32-Bit-C/C++ - Binärcode im 64-Bit-System kann dies aufgrund von Inkompatibilität der Plattform auftreten. Sie können es unter Build> Configuration Manager ändern.

0