Nunit.exe no puede funcionar en Vista 64bits si se genera x86

Question

Estoy en Vista de 64 bits y tengo un proyecto creado con configuración x86. Todo funciona bien. Ahora, estamos en el momento de crear la prueba. Tenemos NUnit 2.4.8 pero tenemos muchos problemas.

La prueba se está cargando a través de Nunit.exe (gui) cuando seleccionamos la .dll directamente, pero al ejecutar tenemos una system.badimageformatexception.

He leído buscando en Google algunos trucos sobre nunit.exe.config pero ninguno funciona. (cambiando a UTF8 ... descomente la versión .net para el inicio).

¿Alguna idea?

Actualizar

He limpiado la solución y borro todas las carpetas BIN. Ahora cuando compilo veo claramente que solo tengo / x86 / en el directorio bin y no el / debug / antiguo que estaba en x64.

Cuando voy con Nunit tengo una excepción (en la carga): System.IO.FileNotFoundException...

Seguimiento de la pila del servidor:    en System.Reflection.Assembly._nLoad (AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark & ??amp; stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)    en System.Reflection.Assembly.InternalLoad (AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark & ??amp; stackMark, Boolean forIntrospection)    en System.Reflection.Assembly.InternalLoad (String assemblyString, Evidence assemblySecurity, StackCrawlMark & ??amp; stackMark, Boolean forIntrospection)    en System.Reflection.Assembly.Load (String assemblyString)    en NUnit.Core.Builders.TestAssemblyBuilder.Load (ruta de la cadena)    en NUnit.Core.Builders.TestAssemblyBuilder.Build (String assemblyName, Boolean autoSuites)    en NUnit.Core.Builders.TestAssemblyBuilder.Build (String assemblyName, String 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 (paquete TestPackage)    en NUnit.Core.RemoteTestRunner.Load (paquete TestPackage)    en System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage (IntPtr md, Object [] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object [] & amp; outArgs)    en System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage (IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Excepción devuelta en [0]:    en System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage (IMessage reqMsg, IMessage retMsg)    en System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke (MessageData & amp; msgData, tipo Int32)    en NUnit.Core.TestRunner.Load (paquete TestPackage)    en NUnit.Util.TestDomain.Load (paquete TestPackage)    en NUnit.Util.TestLoader.LoadTest (String testName)

Actualización 2

Estoy compilando con CUALQUIER CPU que he modificado para que sea x86 en lugar de x64. La razón es para el debug . Esto ya ha sido discutido en el enlace anterior. Tengo que confirmar que NUnit se está ejecutando en 64bits mod y Corflags.exe

Answer 1

Ok, encontré la solución en este sitio web . Debe usar \ NUnit-2.4.8 \ bin \ nunit-x86.exe en lugar de \ NUnit-2.4.8 \ bin \ nunit.exe ... ¡¡no sabía que \ bin \ tenía 2 nunit !! !

Gracias a todos

Answer 2

Es probable que el host NUnit se ejecute como un proceso de 64 bits (puede confirmarlo mirando el administrador de tareas). Si el ensamblaje es solo x86, no podrá ejecutarse en ese proceso.

Puede intentar ejecutar corflags en el Ejecutable NUnit para forzarlo a ejecutar x86, utilizando el indicador / 32bit +

Answer 3

Esto también puede suceder cuando se actualiza de TeamCity 3.1 a 4.0 en un servidor de compilación x64 con la plataforma de ejecución MSBuild configurada en x86. El corredor de TeamCity parece tener la plataforma por defecto de manera diferente en 4.0 que en 3.1, no respetando el hecho de que la compilación está ejecutando x86.

En mi caso, la primera solución que funcionó fue agregar una anulación de Plataforma a la llamada NUnit en mi script de MSBuild:

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

(es decir, la forma en que el corredor de prueba de TeamCity forza 32 bits como en las otras sugerencias)

(Esto incluye cuando el objetivo de la plataforma para el ensamblaje de prueba es Cualquier CPU (aunque a medida que sucede, los he establecido en x86 explícitamente, ya que algunas pruebas cargan archivos DLL que están restringidos a x86)).

Answer 4

¿Por qué estás utilizando la configuración x86 y no cualquier CPU?

Me imagino que cuando cargues NUnit se haya creado con la opción Cualquier CPU, por lo que JIT para el código x64. Cuando esto intenta cargar las pruebas que se compilan específicamente para ejecutarse como x86, se produce la excepción.

Intentaría cambiar todos los ajustes de configuración a Cualquier CPU y ver si esto resuelve tu problema.

Answer 5

Si usa TeamCity, puede agregar la propiedad teamcity.dotnet.nant.nunit2.platform con el valor x86 a los parámetros de compilación en la configuración de su proyecto de TeamCity ( en la sección Propiedades y variables de entorno).

Answer 6

Tenía el mismo problema con TeamCity 8.1. Lo que resolvió fue cambiar el paso de compilación de NUnit .NET Runtime / Platform: a x86

También tuve que cambiar Ejecutar pruebas de: ruta desde TestProject \ bin \ Release a TestProject \ bin \ x86 \ Release