System.BadImageFormatException causado por el proyecto NUnit

Question

Buen día a todos. He estado teniendo el mismo problema todo el día en el trabajo y estoy luchando por encontrar nuevos caminos para bajar.

Recibo el siguiente error cuando mi solución se genera en el servidor. No tengo problemas para ejecutar/depurar todas las pruebas en la solución y funciona bien. Tanto el servidor como mi PC son x64. He seguido muchos consejos que he encontrado en vano.

He establecido el objetivo de la plataforma en x86 para todos los proyectos de mi solución en todas las configuraciones.

Soy consciente de que hay una nunit-console-x86.exe que podría marcar la diferencia, pero no estoy seguro de dónde especificar esto en el código.

Por favor, tenga en cuenta que he hecho búsquedas en Internet, así que le pido disculpas si me he perdido algo.

System.BadImageFormatException: No se pudo cargar el archivo o ensamblado
'Spin.TradingServices.DataAcquisition.Test.NUnit, versión = 1.0.12103.2060, Culture = neutral, PublicKeyToken = null' o uno de sus dependencias . Se intentó cargar un programa con un formato incorrecto . Nombre
del archivo: 'Spin.TradingServices.DataAcquisition.Test.NUnit, versión = 1.0.12103.2060, Culture = neutral, PublicKeyToken = null'

servidor de Seguimiento de la pila: en System.Reflection.RuntimeAssembly._nLoad (AssemblyName nomArchivo, cadena codeBase, assemblySecurity Evidencia, RuntimeAssembly locationHint, StackCrawlMark & stackMark, Boolean throwOnFileNotFound, booleanas forIntrospection, suppressSecurityChecks booleanas) en System.Reflection.RuntimeAssembly.InternalLoadAssemblyName (AssemblyName assemblyRef, assemblySecurity Evidencia, StackCrawlMark & stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks) en System.Reflection.Assembly.Load (AssemblyName assemblyRef) en NUnit.Core.Builders.TestAssemblyBuilder.Load (camino String) en NUnit.Core.Builders.TestAssemblyBuilder.Build (cadena assemblyName, Boolean autoSuites) en NUnit.Core.Builders.TestAssemblyBuilder.Build (String assemblyName, cadena testName, Boolean autoSuites) en NUnit.Core.TestSuiteBuilder.BuildSingleAssembly (paquete TestPackage) en NUnit.Core.TestSuiteBuilder.Build (Paquete TestPackage) en NUnit.Core.SimpleTestRunner.Load (paquete TestPackage) en NUnit.Core.ProxyTestRunner.Load (paquete TestPackage) en NUnit.Core.ProxyTestRunner.Load (Tes paquete tPackage) en NUnit.Core.RemoteTestRunner.Load (paquete TestPackage) en System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage (IntPtr md, objeto args [], servidor de objetos, Int32 methodPtr, Boolean fExecuteInContext, de objetos [] & outArgs) en System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage (I-Mensaje msg, Int32 methodPtr, Boolean fExecuteInContext)

relanza Excepción en [0]: en System.Runtime.Remoting.Proxies. RealProxy.HandleReturnMessage (IMessage reqMsg, IMessage retMsg) en System.Runtime.Remoting.Proxies.RealP roxyPrivateInvoke (MessageData & MSGDATA, el tipo Int32) en NUnit.Core.TestRunner.Load (paquete TestPackage) en NUnit.Util.TestDomain.Load (paquete TestPackage) en NUnit.ConsoleRunner.ConsoleUi.Execute (opciones ConsoleOptions) en NUnit.ConsoleRunner.Runner.Main (String [] args)

WRN: El registro del enlace de ensamblaje está desactivado. Para habilitar el registro de fallas de enlace de ensamblaje, establezca el valor de registro [HKLM \ Software \ Microsoft \ Fusion! EnableLog] (DWORD) en 1. Nota: Hay es una penalización de rendimiento asociada con el error de vinculación de ensamblaje logging. Para desactivar esta función, elimine el valor de registro [HKLM \ Software \ Microsoft \ Fusion! EnableLog].

http://app1017-build.oy.gb.sportingindex.com:8080/job/TradingServices.DataAcquisition-Dev/ws/DataAcquisition/build.proj(86,5): error MSB6006: "nunit-console.exe" salió con el código -100. Hecho proyectos de construcción (objetivos predeterminados) " - FALLO

compilación falló

POR FAVOR:... Hemos revertido nuestra acumulación de Hudson y ahora volver a cometer los archivos de forma más gradual I informará sobre cómo va esto. Intentó conseguir un par de cabezas involucradas en este caso fue en vano por desgracia. la vergüenza!

actualización no he vuelto a esta página por un tiempo pero parece que hay muchas soluciones diferentes. ¡Si pudiera marcarlos a todos como la respuesta que tendría! Aquellos de ustedes que encuentren su camino aquí probablemente den igual crédito a cada opción.

Answer 1

Compruebe que la versión del marco de destino de su conjunto sea la misma que nUnit test runner compatible. Consulte runFile.exe.config para obtener una lista de los tiempos de ejecución admitidos.

Además, si ha pasado de FW 3 a FW 4, tienen un tiempo de ejecución diferente (CLR es diferente).

Answer 2

Tuve este problema con una aplicación de consola en X64 pc, la compilación se configuró como x86 y aún se bloqueó. Ingresé a Propiedades en la aplicación de la consola y en la compilación cambié mi objetivo de plataforma de x86 a cualquier CPU y de repente todas las pruebas funcionaron y se ejecutaron con éxito.

de nota, el campo de la plataforma de Configuration Manager puede "mentirle" y no tiene que reflejar para qué están realmente configuradas las propiedades del proyecto. Mi administrador de configuración dijo que "Common.dll" se estaba construyendo como "Cualquier CPU", pero las propiedades del proyecto (la configuración que realmente importa) era construirlo como "x86".

Answer 3

Ashes999 Gracias por despertarme.

Este problema volvió de nuevo. Y retroceder y cargar no funcionó. Resultó ser un objeto de monitor que ya no usamos. Comentado y arreglado

La manera de encontrar esto es haciendo las pruebas de Debug All Unit. Arregle en donde se detenga. Si t no pausa, entonces err.

Answer 4

Esto puede sonar estúpido, pero, verifique las arquitecturas de su proyecto y procesador.En mi caso, estaba ejecutando pruebas de 64 bits en lo que asumí era una máquina de 64 bits (ya que estaba construyendo proyectos de 64 bits).

¿Adivina qué? En realidad era una máquina de 32 bits. Así que NUnit.exe se ejecutó como de 32 bits (obviamente), y no puede entender las pruebas de 64 bits.

¿La solución? Cree una versión x86 y x64 de sus pruebas, y ejecute las x86 en las máquinas x86, y las x64 en las máquinas x64.

Obvious. Pero vale la pena echarle un vistazo.

Answer 5

Me encuentro con esto a menudo, cuando pruebo contra la aplicación de consola o WPF. Unos causas son

• En primer lugar, asegúrese de que la aplicación no se ejecuta en .Net Framework 3 o 4 Perfil del cliente
• luego comparar la versión de .NET Framework de destino en los dos proyectos de aplicación y de prueba. Deberían ser lo mismo
• Comprobar el objetivo de la plataforma en la pestaña de compilación. Deberían ser iguales. Por ejemplo, si el proyecto de prueba tiene el objetivo "Any CPU", la aplicación debe tener "Any CPU".

Answer 6

Para mí, la excepción fue causada por el argumento /process=single no válido de nunit. Si cambio el valor, entonces la excepción se ha ido:

/process=separate 

o

/process=multiple 

p/s: Respuesta tarde, pero apenas para la referencia ..

Answer 7

Una pequeña adición a todas las respuestas . Es posible que necesite cambiar la plataforma del corredor NUnit (Resharper para mí) como lo hizo en mi caso. Vea el ejemplo

Answer 8

Mi situación era un poco diferente. El error apareció bastante al azar después de ejecutar una prueba unitaria que se había modificado.

Quité la prueba y el error desapareció.

He recreado la prueba y ha aparecido el error.

Cambié el nombre de la prueba y el error desapareció.

Cambié el nombre de la prueba y el problema no volvió a ocurrir.

Espero que esto ayude!

Ben

Answer 9

Para cualquier persona que todavía tiene este tema, también puede ser necesario para establecer el campo marco sobre el corredor de prueba para que coincida con el de su proyecto incluido (El campo justo a la derecha del uno al que hace referencia AlexM)

En mi caso, estaba escribiendo un banco de pruebas para una biblioteca de Windows Phone 8, y NUnit no pudo encontrar correctamente la versión de marco que debería usar.

Answer 10

Asegúrese de que esta configuración sea correcta: Menú Prueba -> Configuración de prueba -> Arquitectura predeterminada del procesador -> x64/x86. No fue correcto en mi caso y falló con el mismo problema.