2009-10-30 5 views
171

Ich habe gerade eine Revision von Subversion in einen neuen Ordner ausgecheckt. Eröffnet die Lösung und ich bekomme dies beim Ausführen:Die Datei oder Baugruppe 'xxx' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Es wurde versucht, ein Programm mit einem falschen Format zu laden.

Konnte Datei oder Assembly 'xxxx' oder eine seiner Abhängigkeiten nicht laden. Es wurde versucht, ein Programm mit einem falschen Format zu laden.

Dies ist der gleiche Code, den ich vor einiger Zeit eingecheckt hatte. Warum macht es das jetzt? Ich sehe jetzt auch ein Debug x86 statt nur Debug in diesem bin-Ordner des xxx-Projekts. Was ist Debug x86 und warum habe ich nicht nur Debuggen wie im bin-Ordner?

+2

Haben Sie versucht, eine Wiederherstellung alles zu tun? Manchmal behebt dies merkwürdige Abhängigkeitsprobleme für mich ... – mezoid

Antwort

229

Klingt wie ein Teil des Projekts für x86-nur gebaut wird, während der Rest für jede CPU/x64 gebaut wird. Das hat mich auch gebissen. Laufen Sie eine x64 (oder äh ... IA64)?

Überprüfen Sie die Projekteigenschaften und stellen Sie sicher, dass alles für "Any CPU" erstellt wird. Wenn Sie in Visual Studio sind, können Sie alles überprüfen, indem Sie in der Symbolleiste oben im Bildschirm auf das Menü "x86" oder "Beliebige CPU" (neben dem Menü "Debuggen"/"Freigabe") klicken und auf klicken "Configuration Manager ..."

+1

Es ist auch unter Projekt-> Eigenschaften-> Erstellen oder Debug-> Eigenschaften-> Erstellen. Just update VS2015, Version 14.0.25123.00 Update 2. Dieses Update wurde gerade am 5.10.16 (gestern!) Veröffentlicht. Ich habe festgestellt, dass Platform Target auf x64 gesetzt ist, wodurch der Fehler festgestellt wurde. Einstellung auf "Any CPU" hat es behoben. –

4

Es ist definitiv ein Problem mit einigen der Projekte, die für x86-Kompatibilität anstelle von irgendeiner CPU gebaut werden. Wenn ich raten müsste, würde ich sagen, dass einige der Referenzen zwischen Ihren Projekten wahrscheinlich auf die DLLs in einigen der bin \ debug-Ordner verweisen, anstatt Projektreferenzen zu sein.

Wenn ein Projekt für x86 anstelle von 'Any CPU' kompiliert wird, gehen die DLLs in den Ordner bin \ x86 \ debug anstelle von bin \ debug (wo wahrscheinlich Ihre Referenzen suchen).

In jedem Fall sollten Sie jedoch Projektreferenzen zwischen Ihren Projekten verwenden.

170

Wenn Sie diesen Fehler beim Ausführen der Website in IIS 7+ auf 64-Bit-Servern erhalten, verfügen Sie möglicherweise über 32-Bit-Assembly, und in Ihrem Anwendungspool wird die Option "32-Bit-Anwendungen aktivieren" auf False gesetzt. Setzen Sie dies auf "True" und starten Sie die Site neu, damit sie funktioniert.

+5

@ Mayhem50 Das gleiche hier. Es hängt davon ab, wo der Fehler auftritt. Wenn es über den Visual Studio & Cassini Webserver geht, hat Fraser Recht. Wenn es in IIS7 + auftritt, ist Nicks Antwort wahrscheinlich die wahrscheinlichste Lösung. –

+25

Wann wird Microsoft anfangen, uns bessere Fehlermeldungen zu geben? –

+0

Dies war die perfekte Antwort für mich (bewegte eine Site von IIS6 auf x86 auf IIS 7 auf x64) – DrStalker

6

Die BadImageFormatException auf einer Anwendung auf IIS ausgeführt wird (nicht von VS ausgeführt wird, da Visual Studio, das Problem mit Hilfe der Build für „Any CPU“ fixiert) kann durch folgende Ursachen haben:

Die Seite ist ein ein Server, der x64 ist und die Standardeinstellung des Anwendungspools für 32-Bit-Anwendungen aktivieren war falsch. und Sie 32-Bit-Baugruppen haben

Auf der Ebene von Visual Studio, das Update ist:

  1. Ändern Sie die Projekteinstellung "Target-CPU" auf "AnyCPU"
5

Stellen Sie sicher, überprüfen Ihre Einstellung für "Prefer 32-bit". In meinem Fall hatte Visual Studio 2012 diese Einstellung standardmäßig aktiviert. Der Versuch, alles aus einer externen DLL zu verwenden, ist fehlgeschlagen, bis ich nicht markiert "Prefer 32-bit".

enter image description here

+0

Ich kann dir nicht genug danken für diese obskure, aber relevante Option, die mich gerettet hat! –

28

inetmgr dann zu Anwendung kommen pool-> Erweiterte Einstellungen Ihres Pool-> haben die Option "Enable 32-Bit-Anwendungen" auf true gesetzt; und starten Sie IIS neu. erneut prüfen.!

+0

Das war die Lösung für mich. Die angenommene Antwort war nicht mein Problem. Vielen Dank! – chapman84

+0

Zweitens dies. Ich habe einen neuen App-Pool für meine Website erstellt und vergessen, diese Einstellung zu ändern. – AlbatrossCafe

+1

Das hat es auch für mich behoben. Die einzige andere Sache, die ich ändern musste, war, die Pipeline in "integriert" zu ändern, da dies auch zu einem Fehler führte, nachdem der obige Fix angewendet wurde. – AxleWack

27

Ich hatte diesen Fehler beim Versuch, die schrecklichen Business Objects 4 für. NET SDK zu verwenden.

Sie liefern fünf BusinessObjects * .dll-Dateien, aber alle sind 64-Bit.

meine Webseite Um zu laden, ich auf Tool \ Options, diese Einstellung in VS2013 dann zu klicken Bedarf ändern:

enter image description here

+0

Diese Option existiert nicht für mich. Die einzige Option auf diesem Bildschirm für mich unter Visual Studio 2010 ist "Verwenden von IIS Express für neue dateibasierte Websites und Projekte" –

0

wenn während mit IIS In Visual Studio Express arbeiten und wenn veröffentlicht gescheitert try this: enter image description here

Verwandte Themen