System.BadImageFormatException causato dal progetto NUnit

Question

Buona giornata a tutti. Ho avuto lo stesso problema tutto il giorno al lavoro e sto lottando per trovare nuovi percorsi da percorrere.

Ho riscontrato il seguente errore quando la mia soluzione si è creata sul server. Non ho problemi a eseguire/debuggare tutti i test nella soluzione e va bene. Sia il server che il mio PC sono x64. Ho seguito un sacco di consigli che non ho trovato.

Ho impostato Platform Target su x86 per tutti i progetti nella mia soluzione in tutte le configurazioni.

Sono consapevole che esiste una nunit-console-x86.exe che potrebbe fare la differenza, ma non sono sicuro di dove specificare questo codice.

Si prega di realizzare che ho tracciato internet, quindi scuse se ho perso qualcosa.

System.BadImageFormatException: Impossibile caricare il file o il montaggio
'Spin.TradingServices.DataAcquisition.Test.NUnit, Version = 1.0.12103.2060, Culture = neutral, PublicKeyToken = null' o una delle sue dipendenze . Si è tentato di caricare un programma con un formato non corretto . Nome
File: 'Spin.TradingServices.DataAcquisition.Test.NUnit, Version = 1.0.12103.2060, Culture = neutral, PublicKeyToken = null'

Server stack trace: a System.Reflection.RuntimeAssembly._nLoad (AssemblyName fileName, String codebase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & stackMark, booleano throwOnFileNotFound, booleani forIntrospection, booleani suppressSecurityChecks) a System.Reflection.RuntimeAssembly.InternalLoadAssemblyName (AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark & stackMark, booleano forIntrospection, booleano suppressSecurityChecks) a System.Reflection.Assembly.Load (AssemblyName assemblyRef) a NUnit.Core.Builders.TestAssemblyBuilder.Load (string path) a NUnit.Core.Builders.TestAssemblyBuilder.Build (String AssemblyName, booleano autoSuites) a NUnit.Core.Builders.TestAssemblyBuilder.Build (String AssemblyName, String nometest, booleano autoSuites) a NUnit.Core.TestSuiteBuilder.BuildSingleAssembly (pacchetto TestPackage) a NUnit.Core.TestSuiteBuilder.Build (Pacchetto TestPackage) in NUnit.Core.SimpleTestRunner.Load (pacchetto pacchetto di test) in NUnit.Core.ProxyTestRunner.Load (pacchetto pacchetto di test) in NUnit.Core.ProxyTestRunner.Load (Tes tPackage pacchetto) a NUnit.Core.RemoteTestRunner.Load (pacchetto TestPackage) a System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage (IntPtr md, oggetto [args], server Object, Int32 methodPtr, booleano fExecuteInContext, Object [] & outArgs) a System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage (IMessage msg, Int32 methodPtr, booleano fExecuteInContext)

Eccezione rilanciati a [0]: a System.Runtime.Remoting.Proxies. RealProxy.HandleReturnMessage (IMessage reqMsg, IMessage retMsg) a System.Runtime.Remoting.Proxies.RealP roxy.PrivateInvoke (MessageData & MSGDATA, tipo Int32) a NUnit.Core.TestRunner.Load (pacchetto TestPackage) a NUnit.Util.TestDomain.Load (pacchetto TestPackage) a NUnit.ConsoleRunner.ConsoleUi.Execute (opzioni ConsoleOptions) a NUnit.ConsoleRunner.Runner.Main (String [] args)

WRN: La registrazione del binding di assiemi è disattivata. Per abilitare la registrazione degli errori di bind di assemblaggio, impostare il valore di registro [HKLM \ Software \ Microsoft \ Fusion! EnableLog] (DWORD) su 1. Nota: C'è una penalità legata alle prestazioni associata al logging del bind di assemblaggio . Per disattivare questa funzione, rimuovere il valore di registro [HKLM \ Software \ Microsoft \ Fusion! EnableLog].

http://app1017-build.oy.gb.sportingindex.com:8080/job/TradingServices.DataAcquisition-Dev/ws/DataAcquisition/build.proj(86,5): errore MSB6006: "nunit-console.exe" è terminato con il codice -100. Fatto progetto di costruzione (destinazioni predefinite) " - FALLITO

generazione non riuscita

NOTA BENE:... Abbiamo ripristinato la nostra generazione su Hudson e ora ri-commettere i file più gradualmente I riferirà su come questo va. provato ottenere un paio di teste coinvolti su questo inutilmente purtroppo. Vergogna!

Aggiornamento non sono stato tornare a questa pagina per un po ' ma sembra che ci siano molte soluzioni diverse. Se potessi segnarli tutti come risposta lo farei! Quelli di voi che troveranno la strada qui dovrebbero probabilmente dare uguale credito a ciascuna opzione.

Answer 1

Verificare che la versione del framework di destinazione dell'assembly sia uguale ai supporti nUnit test runner. Vedere runFile.exe.config per l'elenco dei runtime supportati.

Inoltre, se si è trasferiti da FW 3 a FW 4, hanno un tempo di esecuzione diverso (CLR è diverso).

Answer 2

Ho riscontrato questo problema con un'app console su PC X64, , la build è stata impostata come x86 e si è ancora arrestata. Sono entrato in Proprietà sull'app Console e sotto build ho cambiato il mio Platform Target da x86 a Any CPU, quindi improvvisamente tutti i test hanno funzionato e sono stati eseguiti correttamente.

di nota, il campo della piattaforma di Configuration Manager può "mentire" e non deve effettivamente riflettere le proprietà del progetto effettivamente configurate. Il mio gestore di configurazione ha detto che "Common.dll" era in fase di costruzione come "Qualsiasi CPU", ma le proprietà del progetto (l'impostazione che conta davvero) lo stava costruendo come "x86".

Answer 3

Grazie Ashes999 per svegliarmi.

Questo problema è tornato di nuovo. E il rollback e il caricamento con non ha funzionato. Si è rivelato essere un oggetto monitor che non usiamo nemmeno più. Commentato e risolto.

Il modo per trovarlo è eseguendo il debug di tutti i test di unità. Correggere ovunque si fermi. Se t non si ferma, err.

Answer 4

Questo potrebbe sembrare stupido, ma controllare il progetto e le architetture del processore.Nel mio caso, stavo eseguendo test a 64 bit su quello che presumevo fosse una macchina a 64 bit (poiché stava costruendo progetti a 64 bit).

Indovina cosa? In realtà era una macchina a 32 bit. Quindi NUnit.exe funzionava come 32-bit (ovviamente), e non può comprendere i test a 64-bit.

La soluzione? Crea una versione x86 e x64 dei tuoi test ed esegui quelli x86 sulle macchine x86 e quelli x64 sulle macchine x64.

Ovvio. Ma vale la pena controllare.

Answer 5

Mi sono imbattuto spesso in questo, quando eseguo il test contro l'applicazione Console o WPF. Alcuni cause sono

• In primo luogo, assicurarsi che l'applicazione non funziona su Net Framework 3 o 4 profilo client
• quindi confrontare la versione di .NET framework di destinazione su entrambi i progetti applicativi e di test. Dovrebbero essere uguali
• Controllare l'obiettivo della piattaforma nella scheda di creazione. Dovrebbero essere uguali. Ad esempio, se il progetto di test ha il target "Qualsiasi CPU", l'applicazione deve disporre di "Qualsiasi CPU".

Answer 6

Per me, l'eccezione è stata causata dall'argomento non valido /process=single di nunit. Se cambio il valore, allora l'eccezione è andato:

/process=separate 

o

/process=multiple 

p/s: risposta in ritardo, ma appena per riferimento ..

Answer 7

La minore aggiunta a tutte le risposte . Potrebbe essere necessario cambiare la piattaforma NUnit runner (Resharper for me) come era nel mio caso. Vedere l'esempio

Answer 8

La mia situazione era un po 'diversa. L'errore è apparso in modo abbastanza casuale dopo aver eseguito un test unitario che era stato modificato.

Ho rimosso il test e l'errore è andato via.

Ho ricreato il test e l'errore è tornato.

Ho rinominato il test e l'errore è andato via.

Ho rinominato il test e il problema non si è ripetuto.

Spero che questo aiuti!

Ben

Answer 9

Per chiunque continui ad avere questo problema, è anche potrebbe essere necessario impostare il campo quadro sul test runner per corrispondere a quello del vostro progetto incluso (Il campo appena a destra di quello a cui fa riferimento AlexM).

Nel mio caso, stavo scrivendo una suite di test per una libreria Windows Phone 8 e NUnit non è stato in grado di calcolare correttamente la versione del framework che dovrebbe utilizzare.

Answer 10

Assicurarsi che questa impostazione sia corretta: Menu test -> Impostazioni test -> Architettura processore predefinita -> x64/x86. Nel mio caso non era corretto e non è riuscito con lo stesso problema.