Datei oder Assembly konnte nicht geladen werden ... Es wurde versucht, ein Programm mit einem falschen Format zu laden (System.BadImageFormatException).

Ich habe zwei Projekte ProjectAund ProjectB. ProjectBist eine Konsolenanwendung, die davon abhängt ProjectA. Gestern hat alles gut funktioniert, aber heute, wenn ich renne, ProjectBbekomme ich plötzlich 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.

Beide sind nur reguläre Projekte ohne Abhängigkeiten von anderen Nicht-Net-Projekten. Beide sind vollständig .Net - es gibt keinen nativen Code und kein P / Invoke. Ich habe andere Projekte, die davon abhängen ProjectAund immer noch gut funktionieren.

Dinge, die ich versucht habe:

• Stellen Sie sicher, dass beide Projekte auf "Beliebige CPU" eingestellt sind , und aktivieren Sie das Kontrollkästchen " Erstellen" . Sie sind.
• Stellen Sie sicher, dass beide Projekte für dasselbe Zielframework (.Net 4.0-Clientprofil) gelten .
• Stellen Sie unter ProjektB -> Verweise -> ProjektA -> Eigenschaften sicher, dass "Lokal kopieren" auf "Wahr" _ gesetzt ist (ich habe überprüft, ob ProjectA.dll korrekt kopiert wird).
• Reinigen / Erstellen Sie die Lösung neu. 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.
• Schauen Sie sich eine völlig neue Kopie des Repositorys an.

Aber ich bekomme immer noch den gleichen Fehler. Ich habe keine Ahnung, was ich getan habe, um dies zu verursachen, und wie ich es beheben kann. Irgendwelche Ideen?

Ich bin mir ziemlich sicher, dass Sie einen 32-Bit / 64-Bit-Konflikt haben. Es hört sich so an, als ob Ihr Hauptprojekt auf 32-Bit eingestellt ist, während die Klasse, auf die es verweist, auf 64-Bit eingestellt ist. Schauen Sie sich diese und diese SO-Frage an . Zwischen den beiden sollten Sie in der Lage sein, Ihr Problem herauszufinden.

Möglicherweise haben Sie nach der Bereitstellung auf dem Server Probleme mit Ihrer Website.

Anschließend müssen Sie Ihren Anwendungspool auf 32-Bit-Anwendungen aktivieren einstellen .

Schritte

1. Öffnen Sie den IIS-Manager
2. Klicken Sie auf Anwendungspools
3. Wählen Sie den von Ihnen verwendeten Anwendungspool aus

4. Klicken Sie im rechten Bereich auf Erweiterte Einstellungen ...

5. Setzen Sie 32-Bit-Anwendungen aktivieren auf True

   

Ich hatte gerade diese Fehlermeldung beim Ausführen von IIS Express in Visual Studio 2015. In meinem Fall musste ich die 64-Bit-Version von IIS Express ausführen:

Extras → Optionen → Projekte und Lösungen → Webprojekte Aktivieren
Sie das Kontrollkästchen "Verwenden Sie die 64-Bit-Version von IIS Express für Websites und Projekte".

Bildschirmfoto:

Ich hatte das gleiche Problem. Ich hatte das "Plattformziel" von Projekt A ("Projekt A" (Rechtsklick) -> Eigenschaften -> Erstellen -> "Plattformziel") auf x86 gesetzt, aber das von Projekt B auf "Beliebige CPU" belassen. Das Setzen von Projekt B auf "x86" hat dies behoben.

Ich hatte dieses Problem beim Ausführen von Komponententests (xunit) in Visual Studio 2015 und bin auf das folgende Update gestoßen:

Menu Bar -> Test -> Test Settings -> Default Processor Architecture -> X64

Sie können das ändern müssen Appication Pool Einstellung auf TRUE in IIS7 „32 - Bit - Anwendungen aktivieren“ , wenn Sie mindestens 1 haben 32 - Bit - DLL \ exe in Ihrem Projekt.

Zunächst einmal habe ich dies in VS2017 mit einem alten Projekt , das ich ein zu machen brauchte winzige Änderungen und upraded alle Projekte Rahmen 4.7.

Einige andere haben erwähnt, dass die Auswahl Any CPUdieses Problem beheben kann.

Es gibt ein paar Stellen, an denen Sie dies tun müssen, und es ist möglicherweise nicht so einfach wie die Auswahl aus der Dropdown-Liste. Das hat es für mich behoben:

1) Hier müssen Sie beides tun:

2) Und auch in Configuration Manager(Rechtsklick auf Lösung)

Aber was ist, wenn es nicht da ist ???

Klicken Sie dann auf Newund wählen Sie diese Einstellungen: ( danke @RckLN )

Ich hatte das gleiche Problem mit mehreren Projekten in derselben Lösung. Am Ende stellte ich alle Zielframeworks auf .NET Framework 4 und x86 für die Ziel-CPU ein und es wurde schließlich erfolgreich kompiliert.

Möglicherweise tritt dieses Problem auch auf, wenn Sie versuchen, ein 64-Bit-Projekt mit einem MSI-Installationsprogramm in VS zu verpacken. ("Der Grund dafür ist, dass das mit der MSI-Datei gepackte native Shim 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

Keine dieser Lösungen hat bei mir funktioniert - aber durch das Löschen des Inhalts der Ordner bin und obj war alles wieder cool.

Ich habe dies beim Erstellen eines Projekts über Visual Studio Online (VSTS) Build mit Visual Studio BuildSchritten erhalten.

Die Lösung war:

• Löschen Sie den vorhandenen Quellordner
• Legen Sie explizit 'Beliebige 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

Folgendes löste das Problem für mich, indem Sie das Kontrollkästchen "32-Bit bevorzugen" deaktivieren:

Ich bin auf das gleiche Problem gestoßen. Es tauchte aus heiterem Himmel auf und das kam mir seltsam vor.

Im Ausnahme-Snapshot für das FusionLog wurde in der Nachricht Folgendes angezeigt:

... C: \ Windows \ Microsoft.NET \ Framework64 ...

Weitere Informationen zum Fusionsprotokoll: http://msdn.microsoft.com/en-us/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.

Ich bin mir nicht sicher, wie die Verwechslung der Ziel-CPU ohne ersichtlichen Grund aufgetreten ist, aber es war so.

Ich stehe auch dieses Problem in einem Projekt, nach ein paar Minuten ich die Lösung gefunden, dieses Problem ist auf CPU - Konfiguration Wenn Sie mit Visual Studio 2010 oder VS 2013 , nur goto Projekt ‚s Eigenschaften und wählen Sie dann Compile von Seitenleiste und es wird 5 Dropdowns geben, 5. Dropdown wird Ziel-CPU sein :, Sie sollten es auf x86 oder x64 entsprechend Ihren Anforderungen anstelle von Beliebiger CPU einstellen .

Mein Problem wurde gelöst, nachdem ich es auf x86 geändert hatte.

Dies kann auch passieren, indem mehrere unterstützte Frameworks in der Datei app.config definiert werden und die App gezwungen wird, in einem anderen .NET-Framework als dem zuerst in der Datei app.config genannten auszuführen .

Dies wird auch ausgelöst, wenn beide genannten Frameworks in Ihrem System verfügbar sind.

Rufen Sie als Problemumgehung das Zielframework auf, das Sie für das Debuggen 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"/>

In meinem Projekt für C #, Projekteigenschaft -> [Erstellen] -> Plattformziel: Beliebige CPU, und deaktivieren Sie die Option 32-Bit bevorzugen, damit der Compiler automatisch auswählen kann.

Für die Chilkat .NET 4.5-Assembly muss die VC ++ 2012- oder 2013-Laufzeit auf jedem Computer installiert sein, auf dem Ihre Anwendung ausgeführt wird. Auf den meisten Computern ist es bereits installiert. Ihr Entwicklungscomputer wird es haben, weil Visual Studio installiert wurde. Wenn Sie jedoch auf einem Computer bereitstellen, auf dem die erforderliche VC ++ - Laufzeit nicht verfügbar ist, tritt der oben genannte Fehler auf:

Installieren Sie alle folgenden Pakete

Weiterverteilbare Visual C ++ - Pakete für Visual Studio 2013 - vcredist_x64

Weiterverteilbare Visual C ++ - Pakete für Visual Studio 2013 - vcredist_x86

Weiterverteilbare Visual C ++ - Pakete für Visual Studio 2012 - vcredist_x64

Weiterverteilbare Visual C ++ - Pakete für Visual Studio 2012 - vcredist_x86

Wenn Sie LibreOffice aus Ihrem Programm über die cli .net-Integration wie ich verwenden, wird der gleiche Fehler angezeigt. 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 die Lösung hier gefunden .NET CLI: Datei oder Assembly 'cli_cppuhelper' konnte nicht geladen werden.

Es kann ein bisschen lustig sein, aber ich hatte das gleiche Problem mit normalem Arbeitscode. Ich habe StreamWriter und StreamReader hinzugefügt und es gab diesen Fehler. Die Lösung war, dass ich diesen Code in Kommentarklammern nahm, dann debuggte und es wieder funktionierte

Ich hatte auch dieses Problem beim Ausführen von Komponententests mit ReSharper unter Visual Studio 2017 und habe es mit der folgenden Konfiguration behoben:

Sie können auch die Testeinstellung des ReSharper ändern: https://resharper-support.jetbrains.com/hc/en-us/articles/207242715-How-to-run-MSTest-tests-using-x64-configuration

In meinem Fall fehlte eine Abhängigkeit in der DLL, die diese Ausnahme auslöste. Ich habe mich bei Dependency Walker erkundigt, die fehlende DLL hinzugefügt und das Problem wurde behoben.

Insbesondere habe ich meine opencv_core340.dll irgendwie beschädigt, indem ich versehentlich SVN-Schlüsselwörter hinzugefügt habe, und daher konnte meine DLL sie nicht mehr verwenden. Ich glaube jedoch nicht, dass die Lösung dieses Problems davon abhängt, ob die DLL beschädigt ist oder fehlt. Ich füge dies nur hinzu, um vollständige Informationen zu geben.

Schießen! Ich wusste von diesem Problem. Ich dachte, ich mache alles richtig, bis ich versehentlich 'x86' im VS-Ausgabefenster sah, und dann bekam ich die Ursache. Ich habe heute ein paar Minuten damit verschwendet.

Die Konfiguration unter "Veröffentlichen" wurde auf "x86" festgelegt. wohingegen es überall "x64" war.

Stellen Sie sicher, dass die Konfiguration zwischen Konfigurationsmanager, Veröffentlichungseinstellungen, Lösungskonfigurationen und IIS-Einstellungen synchron ist (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.

Ich habe etwas anderes als die anderen Antworten entdeckt. Das Erreichen dieser Ausnahme in meinem Projekt war das Ergebnis einer beschädigten Kompilierung. Ohne Änderungen vorzunehmen, nur die Neuerstellung zu erzwingen, wurde dies behoben.

Ich hatte das gleiche Problem. In meinem Fall war Projekt B eine .Net Core Class Library, auf der ein Nuget "Microsoft.Management.Infrastructure" installiert ist. Der Fehler war, dass ich mein Projekt B "MI" nannte. Ich habe den Projektnamen in etwas anderes geändert und plötzlich hat alles wieder funktioniert.

Mein Computer hat mir ein BIOS-Update angezeigt und ich habe mich gefragt, ob dies mit dem plötzlichen Auftreten dieses Fehlers zu tun hat. Und nachdem ich das Update durchgeführt hatte, wurde der Fehler behoben und die Lösung einwandfrei erstellt.

Versuchen Sie, Ihre EXE-Datei über das Cmd auszuführen? Das war mein Fehler. Führen Sie einfach die EXE-Datei aus, indem Sie darauf doppelklicken. Wenn es sich um eine .NET Core SCD für Windows 8.1 / Windows Server 2012 R2 x64 handelt.