System.BadImageFormatException verursacht durch NUnit-Projekt
Guten Tag alle. Ich habe das gleiche problem den ganzen Tag auf der Arbeit und bin kämpfen, um zu finden, neue Wege zu gehen.
Ich erhalte die folgende Fehlermeldung, wenn meine Lösung baut auf dem server. Ich habe kein problem, laufen/Debuggen alle tests in der Lösung und baut Sie in Ordnung. Beide server und mein PC sind x64. Ich habe eine Menge Ratschläge, die ich gefunden habe ohne Erfolg.
Habe ich Plattform Ziel auf x 86 für alle Projekte in meiner Lösung unter allen Konfigurationen.
Ich bin mir bewusst, dass es eine nunit-console-x86.exe die könnte den Unterschied machen, aber ich bin mir nicht sicher, wo Sie angeben, dass diese in den code.
Bitte begreife, dass ich habe Weg-brannte im internet, also entschuldigt, wenn ich etwas verpasst haben.
System.BadImageFormatException: Konnte nicht geladen, Datei oder assembly
'Spin.TradingServices.DataAcquisition.Test.NUnit,
Version=1.0.12103.2060, Culture=neutral, PublicKeyToken=null " oder eine
seine Abhängigkeiten. Es wurde versucht, ein Programm laden mit einer
falsche format.
Datei name:
'Spin.TradingServices.DataAcquisition.Test.NUnit,
Version=1.0.12103.2060, Culture=neutral, PublicKeyToken=null'Server stack-trace:
System.Reflexion.RuntimeAssembly._nLoad(AssemblyName fileName, String-codeBase, Beweise assemblySecurity, RuntimeAssembly
locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound,
Boolean forIntrospection, Boolean suppressSecurityChecks)
System.Reflexion.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName
assemblyRef, Beweise assemblySecurity, StackCrawlMark& stackMark,
Boolean forIntrospection, Boolean suppressSecurityChecks)
System.Reflexion.Montage.Load(AssemblyName assemblyRef)
bei NUnit.Core.Bauherren.TestAssemblyBuilder.Load(String path)
bei NUnit.Core.Bauherren.TestAssemblyBuilder.Build(String assemblyName, Boolean autoSuites)
bei NUnit.Core.Bauherren.TestAssemblyBuilder.Build(String assemblyName, String testName, Boolean autoSuites)
bei NUnit.Core.TestSuiteBuilder.BuildSingleAssembly(TestPackage-Paket)
bei NUnit.Core.TestSuiteBuilder.Bauen(TestPackage-Paket)
bei NUnit.Core.SimpleTestRunner.Belastung(TestPackage-Paket)
bei NUnit.Core.ProxyTestRunner.Belastung(TestPackage-Paket)
bei NUnit.Core.ProxyTestRunner.Belastung(TestPackage-Paket)
bei NUnit.Core.RemoteTestRunner.Belastung(TestPackage-Paket)
System.- Laufzeit.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr
md, Object[] args, Object server, Int32 methodPtr, Boolean
fExecuteInContext, Object[]& outArgs)
System.- Laufzeit.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage
msg, Int32 methodPtr, Boolean fExecuteInContext)Ausnahme erneut ausgelöst, auf [0]:
System.- Laufzeit.Remoting.Proxys.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessage retMsg)
System.- Laufzeit.Remoting.Proxys.RealProxy.PrivateInvoke(MessageData&
msgData, Int32-Typ)
bei NUnit.Core.TestRunner.Belastung(TestPackage-Paket)
bei NUnit.Util.TestDomain.Belastung(TestPackage-Paket)
bei NUnit.ConsoleRunner.ConsoleUi.Execute(ConsoleOptions Optionen)
bei NUnit.ConsoleRunner.Runner.Main(String[] args)WRN: Protokollierung der assemblybindung ist AUS. Um die Protokollierung der assemblybindungsfehler aktivieren, setzen Sie den Registrierungswert
[HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) auf 1. Hinweis: Es
ist einige performance-Strafe, die verbunden mit der assemblybindungsfehler
die Protokollierung. Dieses feature deaktivieren, entfernen Sie den Registrierungswert
[HKLM\Software\Microsoft\Fusion!EnableLog].http://app1017-build.oy.gb.sportingindex.com:8080/job/TradingServices.DataAcquisition-Dev/ws/DataAcquisition/build.proj(86,5):
Fehler MSB6006: "nunit-console.exe" beendet mit code -100. Getan
Bauvorhaben
"
(Standard-Ziele) -- FEHLER.Build FAILED.
BITTE BEACHTEN Sie: Wir rückgängig gemacht haben unser build auf Hudson und jetzt wieder-einspielen von Dateien Schritt für Schritt. Ich werde berichten, wie das geht. Versucht, Holen Sie sich ein paar Köpfe beteiligt, auf das man ohne Erfolg leider. Schande!
Update
Ich habe nicht zurück zu dieser Seite für eine Weile, aber es sieht aus wie es gibt viele verschiedene Lösungen. Wenn ich könnte, markieren Sie alle, wie die Antwort, die ich würde! Diejenigen von Euch, die finden Ihren Weg hier sollte wohl gleich Kredit zu jeder option.
InformationsquelleAutor Matt Canty | 2012-03-26
Du musst angemeldet sein, um einen Kommentar abzugeben.
Überprüfen Sie die Ziel-framework-version Ihrer Baugruppe sind die gleichen wie nUnit test runner unterstützt.
Sehen runFile.exe.config für die Liste der unterstützten Laufzeitumgebungen.
Auch wenn Sie megrated von FW 3, FW 4, Sie hat verschiedene runtime (CLR).
FW 4 Laufzeit ist 4.[yah ich weiß nicht mehr weiter :)] Runtime 2.xxx FW 2, 3, 3.5. Also versuchen nach vorne zu schauen, auf diese Weise. Update nUnit, überprüfen Sie, Pfade... etc..
Ja, ich habe gerade heruntergeladen nUnit 2.6 nachdem Sie erwähnt die runFile.exe ...
InformationsquelleAutor ili
Ich hatte dieses problem mit einer Konsole app, die auf X64-pc,
das bauen wurde eingestellt, als x86 und es immer noch abgestürzt.
Ich ging in den Eigenschaften auf der Konsole App und unter bauen, änderte ich meine Plattform Ziel von x86, Any CPU dann plötzlich alle tests arbeitete und lief erfolgreich.
ist zu beachten, dass die Configuration Manager-platform-Feld kann die "Lüge" und nicht tatsächlich das widerspiegeln, was die Eigenschaften des Projekts tatsächlich konfiguriert wird, um zu tun. Meine configuration manager sagte, dass "Common.dll" gebaut wurde als "Any CPU", aber die Projekt-Eigenschaften (die Einstellung ist wirklich wichtig) wurde das Gebäude als "x86".
+1 Jeder CPU ändern, fixiert es für mich auch.
+1 Jeder CPU ändern, fixiert es für mich auch 🙂
In vielen Fällen können Sie einfach ändern Sie die target-Plattform, sondern auch in anderen, kann man einfach nicht. Zum Beispiel, wenn Sie eine Verbindung zu MSAccess-Datenbank, die Plattform Ziel muss sein, x86. Ich weiß, es ist bullsh... aber hey Leute, es ist Microsoft.... eine Hass/Liebe Beziehung. 😀
InformationsquelleAutor Theresa Forster
Eine kleine Ergänzung für alle Antworten. Sie müssen möglicherweise ändern Sie die NUnit runner-Plattform (Resharper für mich) selbst, wie es in meinem Fall war.
Siehe Beispiel
InformationsquelleAutor Alex M
Stellen Sie sicher, dass diese Einstellung richtig ist: Test-Menü -> Einstellungen Testen -> Standard-Prozessor-Architektur -> x64 /x86.
Es war falsch, in meinem Fall und es ist fehlgeschlagen mit dem gleichen Problem.
vielen Dank, dass speichern mein Tag
perfekt ist die Einstellung 🙂
InformationsquelleAutor MaurGi
Komme ich über diese oft, wenn ich test gegen Konsolen-oder WPF-Anwendung. Einige Ursachen sind
InformationsquelleAutor Andy
Das klingt vielleicht dumm, aber, überprüfen Sie Ihre Projekt-und Prozessor-Architekturen. In meinem Fall war ich unter der 64-bit-tests auf , was ich annahm, war ein 64-bit-Maschine (da war es die Erstellung von 64-bit-Projekte).
Erraten, was? Es war eigentlich ein 32-bit-Maschine. So NUnit.exe lief als 32-bit - (offensichtlich), und kann nicht verstehen, 64-bit-tests.
Die Lösung? Bauen Sie ein x86-und x64-version des tests, und führen Sie den x86 auf x86-Maschinen, und die x64-diejenigen, die auf der x64-Maschinen.
Offensichtlich. Aber Sie ist es Wert, heraus zu überprüfen.
InformationsquelleAutor ashes999
Für mich, die Ausnahme war, verursacht durch ungültige
/process=singleargument von nunit. Wenn ich den Wert ändern, dann wird die exception ist Weg:oder
p/s: spät Antworte, aber nur zur Information..
InformationsquelleAutor checksum
Meine situation war ein bisschen anders. Der Fehler wurde ganz zufällig nach dem ausführen von Unit Tests, die sich geändert hat.
Entfernte ich den test, und der Fehler ging Weg.
Ich neu erstellt, die test, und der Fehler kam wieder.
Umbenannt habe ich die test, und der Fehler ging Weg.
Umbenannt habe ich den test wieder und das problem trat nicht wieder auf.
Hoffe, das hilft!
Ben
InformationsquelleAutor ben
Dank Ashes999 für weckte mich.
Dieses problem hast, wieder zurückzukehren. Und zurück Rollen und das hochladen von mit hat nicht funktioniert. Es stellte sich heraus, dass ein monitor-Objekt, das wir gar nicht mehr verwenden. Auskommentiert und behoben.
Den Weg zu finden, dieses ist, indem Sie Debuggen, Alle Unit-Tests. Fix überall stecken. Wenn t nicht anhalten, dann err.
InformationsquelleAutor Matt Canty
Für jemand immer noch dieses Problem, diese können Sie auch brauchen, um die framework-Feld auf der test-runner übereinstimmen, die in Ihrem Projekt enthalten (Das Feld nur auf der rechten Seite von der verwiesen wird, die von AlexM).
In meinem Fall, ich Schreibe eine test-suite für Windows Phone 8 Bibliothek und NUnit konnte nicht richtig herausfinden, die framework-version, die Sie verwenden sollten.
InformationsquelleAutor Zenel