Nunit.exe nicht auf Vista 64bits wenn x86-build

Question

Ich bin auf Vista 64 bit und ich habe ein Projekt erstellt mit x86-Konfiguration.Alle funktionieren.Nun, wir sind zur Zeit zu erstellen, zu testen.Wir haben NUnit 2.4.8 aber wir haben eine Menge von problem.

Der test laden durch den Nunit.exe (gui), wenn wir wählen .dll direkt, sondern bei der Ausführung haben wir ein system.badimageformatexception.

Ich habe gelesen bei Google gesucht paar Tricks über die nunit.exe.config aber keine Arbeit.(Wechsel zu UTF-8...kommentieren Sie .net-version, die zum Start).

Irgendeine Idee?

Update

Ich habe saubere Lösung und löschen Sie alle Ordner "BIN".Wenn ich jetzt kompiliere ich deutlich sehen, dass ich nur die /x86/ in das bin-Verzeichnis und nicht die alte /debug/ das war in x64.

Wenn ich mit Nunit ich habe eine Ausnahme (im laden) : System.IO.FileNotFoundException...

Server-stack-trace:System.Reflexion.Montage._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) System.Reflexion.Montage.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) System.Reflexion.Montage.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) System.Reflexion.Montage.Load(String assemblyString) bei NUnit.Kern.Bauherren.TestAssemblyBuilder.Load(String path) bei NUnit.Kern.Bauherren.TestAssemblyBuilder.Build(String assemblyName, Boolean autoSuites) bei NUnit.Kern.Bauherren.TestAssemblyBuilder.Build(String assemblyName, String testName, Boolean autoSuites) bei NUnit.Kern.TestSuiteBuilder.BuildSingleAssembly(TestPackage-Paket) bei NUnit.Kern.TestSuiteBuilder.Build(TestPackage-Paket) bei NUnit.Kern.SimpleTestRunner.Load(TestPackage-Paket) bei NUnit.Kern.ProxyTestRunner.Load(TestPackage-Paket) bei NUnit.Kern.ProxyTestRunner.Load(TestPackage-Paket) bei NUnit.Kern.RemoteTestRunner.Load(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 bei [0]:System.Laufzeit.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) System.Laufzeit.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) bei NUnit.Kern.TestRunner.Load(TestPackage-Paket) bei NUnit.Util.TestDomain.Load(TestPackage-Paket) bei NUnit.Util.TestLoader.LoadTest(String testName)

Update 2

Ich bin kompilieren mit JEDER CPU, die habe ich geändert, x86 statt x64.Der Grund ist für die debug.Dies wurde bereits im vorigen link.Ich habe, um zu bestätigen, dass NUnit ausgeführt wird, bei 64-bit und mod Corflags.exe

Answer 1

Ok, ich fand die Lösung in diesem website.Sie müssen die Unit-2.4.8\bin unit-x86.exe statt Unit-2.4.8\bin unit.exe...wusste nicht, dass das \bin\ 2 nunit!!!

Thx all

Answer 2

Das NUnit-host ist wahrscheinlich die Ausführung als 64-bit-Prozess (Sie können bestätigen, dass sich durch einen Blick in den task-manager).Wenn Sie die Montage ist nur auf x86, dann wird es nicht werden in der Lage zu laufen in diesem Prozess.

Sie können versuchen, corflags auf der NUnit-executable, um ihn zu zwingen, zu laufen, x86, mit der /32bit+ flag

Answer 3

Dies kann auch passieren, wenn Sie ein Upgrade von TeamCity 3.1 auf 4.0 auf einen x64 server erstellen mit MSBuild Ausführen Plattform auf x86.Die TeamCity-Läufer scheint standardmäßig die Plattform anders in 4.0 als 3,1, nicht zu Ehren der Tatsache, dass der build ausgeführt wird, x86.

In meinem Fall ist das erste Update, das funktionierte, war das hinzufügen einer Plattform überschreiben der NUnit-Aufruf in meinem MSBuild-Skript:

<NUnit Assemblies="Test/bin/$(Platform)/$(Configuration)/Test.dll" Platform="x86" /> 

(d.h., die TeamCity-test-runner Weise zwingen 32-bit-wie auch in den anderen Kommentaren)

(Dies gilt auch, wenn die Zielplattform für den Testaufbau ist Jede CPU (obwohl es passiert, ich habe Ihnen x86 explizit als einige tests dynamischen laden von DLLs, die gezwungen sind, x86)).

Answer 4

Warum verwenden Sie das x86-Konfiguration und nicht Jede CPU?

Ich würde mir vorstellen, dass, wenn Sie Last NUnit es ist gebaut worden, mit der Alle CPU-option, so JITs für x64-code.Wenn diese versucht zu laden Sie Ihr tests, die speziell zusammengestellt, um die Ausführung als x86 wirft es die Ausnahme.

Ich würde versuchen, ändern Sie alle Ihre Einstellungen in der Konfiguration für Jede CPU und sehen, ob dies Ihr problem löst.

Answer 5

Wenn Sie mit TeamCity, können Sie die Eigenschaft hinzufügen teamcity.dotnet.nant.nunit2.Plattform mit dem Wert x86 um den Build Parameter in der TeamCity-Projekt-Konfiguration-Einstellungen (in den Eigenschaften und Umgebungsvariablen Abschnitt).

Answer 6

Hatte das gleiche problem mit TeamCity 8.1.Was löste es war eine Veränderung NUnit-build-Schritt .NET-Runtime / Plattform: zu x86

Ich hatte auch ändern Führen Sie tests von: Weg von TestProject\bin elease zu TestProject\bin\x86 elease