Datei oder Assembly konnte nicht geladen werden ... Es wurde versucht, ein Programm mit einem falschen Format zu laden (System.BadImageFormatException).
Ich habe zwei Projekte, ProjectA und ProjectB. ProjectB ist eine Konsolenanwendung, die von ProjectA abhängt. Gestern hat alles gut funktioniert, aber plötzlich, wenn ich ProjectB starte, bekomme ich Folgendes:
BadImageFormatException wurde nicht behandelt :
Datei oder Assembly 'ProjectA, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Es wurde versucht, ein Programm mit einem falschen Format zu laden.
Bei beiden handelt es sich nur um reguläre Projekte, die keine Abhängigkeiten zu anderen Nicht-.NET-Projekten haben. Beide sind vollständig .Net - es gibt keinen nativen Code und kein P/Invoke. Ich habe andere Projekte, die auf ProjectA angewiesen sind und trotzdem gut funktionieren.
Dinge, die ich ausprobiert habe:
- Stellen Sie sicher, dass beide Projekte auf "Beliebige CPU" eingestellt sind und das Kontrollkästchen build aktiviert ist. Sie sind.
- Stellen Sie sicher, dass beide Projekte für dasselbe Ziel-Framework (.Net 4.0-Clientprofil) sind.
- Stellen Sie unter ProjectB -> References -> ProjectA -> Properties sicher, dass "Copy Local" auf "True" _ gesetzt ist (ich habe überprüft, dass ProjectA.dll korrekt kopiert wird)
- Lösung reinigen/neu erstellen. Ich habe sogar versucht, die Ordner/bin und/obj in beiden Projekten manuell zu löschen.
- Starten Sie Visual Studio neu. Starten Sie meinen Computer neu.
- Checke eine komplett neue Kopie des Repositorys aus.
Aber ich bekomme immer noch den gleichen Fehler. Ich habe keine Ahnung, was ich getan habe, um das Problem zu beheben. Irgendwelche Ideen?
Ich bin mir ziemlich sicher, dass Sie einen 32-Bit/64-Bit-Konflikt haben. Es scheint, als könnte Ihr Hauptprojekt auf 32 Bit gesetzt sein, während die Klasse, auf die verwiesen wird, auf 64 Bit eingestellt ist. Schauen Sie sich diese SO - Frage an und auch diese . Zwischen den beiden sollten Sie in der Lage sein, Ihr Problem herauszufinden.
Möglicherweise haben Sie nach der Bereitstellung auf dem Server ein Problem mit Ihrer Website.
Dann müssen Sie Ihren Anwendungspool so einstellen, dass 32-Bit-Anwendungen aktiviert werden.
Schritte:
- Öffnen IIS Manager
- Klicken Sie auf Anwendungspools
- Wählen Sie den von Ihnen verwendeten Anwendungspool aus
- Klicken Sie im rechten Bereich auf Erweiterte Einstellungen ...
- Setzen Sie Enable 32-Bit Applications auf True
Ich hatte gerade diese Fehlermeldung, dass IIS Express in Visual Studio 2015 ausgeführt wurde. In meinem Fall musste die 64-Bit-Version von IIS Express ausgeführt werden:
Extras -> Optionen -> Projekte und Lösungen -> Webprojekte
Aktivieren Sie das Kontrollkästchen das besagt "Verwenden Sie die 64-Bit-Version von IIS Express für Websites und .__-Projekte".
Bildschirmfoto:
Ich hatte das gleiche Problem. Ich hatte Project As "Platform Target" ("Project A" (Rechtsklick) -> Eigenschaften -> Erstellen -> "Platform Target") auf x86 gesetzt, aber Project Bs auf "Any CPU" belassen. Das Festlegen von Project Bs auf "x86" wurde behoben.
Ich hatte dieses Problem beim Ausführen von Komponententests (xunit) in Visual Studio 2015 und fand das folgende Update:
Menu Bar -> Test -> Test Settings -> Default Processor Architecture -> X64
Möglicherweise müssen Sie die Einstellung Appication Pool "Enable 32bit Applications" in IIS7 auf TRUE setzen, wenn sich in Ihrem Projekt mindestens 1 32bit-DLL befindet.
Zuallererst bekam ich das in VS2017 mit einem alten Projekt, das ich brauchte, um eine tiny - Änderung vorzunehmen und alle Projekte auf das Framework 4.7 umzustellen.
Einige andere haben erwähnt, dass Any CPU das Problem beheben kann.
Es gibt ein paar Stellen, an denen Sie dies tun müssen, und es ist möglicherweise nicht so einfach wie das Auswählen aus dem Dropdown-Menü. Das hat es für mich behoben:
1) Sie müssen es beide hier tun:
2) Und auch in Configuration Manager (Rechtsklick auf Lösung)
Aber was ist, wenn es nicht da ist?
Klicken Sie dann auf New und wählen Sie diese Einstellungen: ( Danke @RckLN )
Möglicherweise wird dieses Problem auch angezeigt, wenn Sie versuchen, ein 64-Bit-Projekt mit einem MSI-Installationsprogramm in VS zu packen. ("Der Grund ist, dass das native Shim, das mit der .msi-Datei gepackt ist, eine ausführbare 32-Bit-Datei ist.")
Weitere Informationen finden Sie hier: http://blogs.msdn.com/b/heaths/archive/2006/02/01/64-bit-managed-custom-actions-with-visual-studio.aspx
Ich hatte das gleiche Problem mit mehreren Projekten in der gleichen Lösung. Ich stellte alle Zielframeworks auf .NET Framework 4 und x86 für die Ziel-CPU ein und es wurde erfolgreich kompiliert.
Ich habe dies beim Erstellen eines Projekts über Visual Studio Online (VSTS) Build mit Visual Studio Build Steps erhalten.
Die Lösung war:
- Löschen Sie den vorhandenen Quellordner
- Legen Sie explizit "Any CPU" in der Plattform für alle Visual Studio Builds einschließlich Abhängigkeiten fest (siehe Abbildung unten).
- Führen Sie den Build erneut aus
Keine dieser Lösungen funktionierte für mich - aber durch das Löschen des Inhalts der Ordner bin und obj war alles wieder cool.
Ich stehe auch vor diesem Problem in einem Projekt. Nach einigen Minuten habe ich die Lösung gefunden. Dieses Problem ist auf die CPU-Konfiguration zurückzuführen. Wenn Sie Visual Studio 2010 oder VS 2013 verwenden, gehen Sie einfach zum Projekt 's properties und dann Compile aus der Seitenleiste auswählen, und es werden 5 Dropdown-Listen angezeigt. 5. Dropdown-Listen sind Ziel-CPU: . Sie sollten sie auf x86 oder setzen x64 nach Ihren Anforderungen statt irgendeiner CPU.
Mein Problem wurde behoben, nachdem ich es in x86 geändert hatte.
In meinem Projekt für C #, Projekteigenschaft -> [Erstellen] -> Plattformziel: Alle CPU.... Und deaktivieren Sie die Option Präfer 32-Bit, damit der Compiler automatisch auswählen kann.
Wenn Sie LibreOffice aus Ihrem Programm über die Integration von cli .net verwenden wie ich, erhielt ich den gleichen Fehler. Ich verwende die ältere Version von LibreOffice in der Produktionsumgebung auf meinem PC. Ich habe eine neuere Version installiert, die in Konflikt stand. Deinstallieren Sie einfach LibreOffice. Ich habe hier die Lösung gefunden .NET CLI: Datei oder Assembly 'cli_cppuhelper' konnte nicht geladen werden
Ich bin auf das gleiche Problem gestoßen. Es erschien aus heiterem Himmel und das kam mir seltsam vor.
In der Momentaufnahme der Ausnahme für FusionLog sah ich Folgendes in seiner Nachricht:
... C:\Windows\Microsoft.NET\Framework64 ...
Weitere Informationen zum Fusionsprotokoll: http://msdn.Microsoft.com/de-de/library/e74a18c4(v=vs.110).aspx
Alle Projekte hatten eine Ziel-CPU von AnyCPU. Ich habe das Anwendungsprojekt (das Projekt, das auf alle anderen Projekte verweist) in eine Ziel-CPU von x86 geändert. Es funktioniert jetzt.
Nicht sicher, wie die Ziel-CPU-Verwechslung ohne ersichtlichen Grund stattfand, tat es aber.
Dies kann auch passieren, wenn mehrere unterstützte Frameworks in der Datei app.config definiert sind und die Anwendung zwangsweise in einem anderen .NET-Framework als dem in der App zuerst genannten ausgeführt wird. Konfigurationsdatei.
Und auch das wird ausgelöst, wenn Sie beide genannten Frameworks in Ihrem System zur Verfügung haben.
Um dieses Problem zu umgehen, rufen Sie das Ziel-Framework auf, das Sie für das Debugging in der app.config verwenden möchten
beispiel: Wenn Sie versuchen, in .NET 4 auszuführen, sollte die Konfigurationsdatei etwas Ähnliches haben.
<supportedRuntime version="v4.0"/>
<supportedRuntime version="v2.0.50727"/>
Für die Chilkat .NET 4.5-Assembly muss die Laufzeitumgebung von VC++ 2012 oder 2013 auf jedem Computer installiert sein, auf dem Ihre Anwendung ausgeführt wird. Die meisten Computer haben es bereits installiert. Ihr Entwicklungscomputer hat es, weil Visual Studio installiert wurde. Bei der Bereitstellung auf einem Computer, auf dem die erforderliche VC++ - Laufzeit nicht verfügbar ist, tritt der obige Fehler auf:
Installieren Sie alle unten aufgeführten Pakete
Umverteilbare Visual C++ - Pakete für Visual Studio 2013 - vcredist_x64
Umverteilbare Visual C++ - Pakete für Visual Studio 2013 - vcredist_x86
Umverteilbare Visual C++ - Pakete für Visual Studio 2012 - vcredist_x64
Umverteilbare Visual C++ - Pakete für Visual Studio 2012 - vcredist_x86
Ich hatte auch dieses Problem beim Ausführen von Komponententests mit ReSharper in Visual Studio 2017 und behebte es mit folgender Konfiguration:
Sie können auch die Lauftesteinstellung des ReSharper ändern: https://resharper-support.jetbrains.com/hc/en-us/articles/207242715-How-to-run-MSTest-tests- using-x64 -Aufbau
Schießen! Ich wusste von diesem Problem. Ich dachte, ich würde alles richtig machen, bis ich versehentlich "x86" im VS-Ausgabefenster sah und dann die Ursache herausfand. Habe heute ein paar Minuten damit verbracht.
Die Konfiguration unter 'Veröffentlichen' wurde auf 'x86' gesetzt; wohingegen es sonst überall "x64" war.
Stellen Sie sicher, dass die Synchronisierung zwischen Konfigurationsmanager, Veröffentlichungseinstellungen, Lösungskonfigurationen und Einstellungen für IIS erfolgt (sofern dies Ihr Webserver ist).
Beachten Sie auch, dass VS eine 32-Bit-App und IIS 64-Bit ist. 32-Bit-Apps sind in IIS standardmäßig deaktiviert.
Es kann ein bisschen lustig sein, aber ich hatte das gleiche Problem mit normalem Arbeitscode. Ich fügte StreamWriter und StreamReader hinzu und gab diesen Fehler ... Die Lösung bestand darin, dass ich den Code in Kommentarklammern nahm, dann debuggte und es wieder funktionierte
In meinem Fall fehlte in der DLL eine Abhängigkeit, die diese Ausnahme auslöste. Ich habe mit Dependency Walker überprüft, die fehlende DLL hinzugefügt und das Problem wurde behoben.
Genauer gesagt, ich habe meine opencv_core340.dll beschädigt, indem ich versehentlich SVN-Schlüsselwörter hinzugefügt habe, und meine DLL konnte sie daher nicht mehr verwenden. Ich glaube jedoch nicht, dass die Lösung für dieses Problem davon abhängt, ob die DLL beschädigt ist oder fehlt. Ich füge das nur hinzu, um vollständige Informationen zu geben.