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

Question

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

La prueba se carga a través del Nunit.exe (gui) cuando seleccionamos el archivo .dll directamente, pero cuando lo ejecutamos tenemos un sistema. Badimageformaception.

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

¿Alguna idea?

actualización

que tienen la solución limpia, y borrar la carpeta BIN. Ahora, cuando compilo, veo claramente que tengo solo el/x86/en el directorio bin y no el antiguo/depuración/que estaba en x64.

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

servidor de Seguimiento de la pila: en System.Reflection.Assembly._nLoad (AssemblyName nombre de fichero, cadena codeBase, Evidencia assemblySecurity, Asamblea locationHint, StackCrawlMark & stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) en System.Reflection.Assembly.InternalLoad (AssemblyName assemblyRef, assemblySecurity Evidencia, StackCrawlMark & stackMark, Boolean forIntrospection) en System.Reflection.Assembly. InternalLoad (String assemblyStrin g, assemblySecurity Evidencia, StackCrawlMark & stackMark, Boolean forIntrospection) en System.Reflection.Assembly.Load (String assemblyString) en NUnit.Core.Builders.TestAssemblyBuilder.Load (camino String) en NUnit.Core.Builders.TestAssemblyBuilder. construir (String 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. Genere (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, Object [] args, servidor de objetos, Int32 methodPtr, Boolean fExecuteInContext, Object [] & outArgs) en System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage (msg I-Mensaje, 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.RealProxy.PrivateInvoke (MessageData & msgData, tipo Int32) en NUnit.Core.Te stRunner.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 ser 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

Bien Encontré la solución en este website. Tienes que usar el \ NUnit-2.4.8 \ bin \ nunit-x86.exe en lugar de \ NUnit-2.4.8 \ bin \ nunit.exe ... ¡no sabía que el \ bin \ tenía 2 nunit! !

Thx todo

Answer 2

El host NUnit probablemente se está ejecutando como un proceso de 64 bits (puede confirmarlo al buscar en el administrador de tareas). Si su ensamblaje es x86 solo entonces no podrá ejecutarse en ese proceso.

Usted puede intentar ejecutar corflags en el NUnit ejecutable para obligarlo a ejecutar X 86, usando el/32bit + bandera

Answer 3

¿Por qué utiliza la configuración x86 y no Cualquier CPU?

Me imagino que cuando carga NUnit se ha construido con la opción Cualquier CPU, por lo que JITs a código x64. Cuando esto intenta cargar las pruebas que están específicamente compiladas para ejecutarse como x86 arroja la excepción.

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

Answer 4

Esto también puede ocurrir cuando se actualiza de TeamCity 3.1 a 4.0 en un x 64 servidor acumulación con la Plataforma de ejecución MSBuild establece en x86. El corredor de TeamCity parece predeterminar la plataforma de manera diferente en 4.0 que 3.1, sin respetar el hecho de que la compilación se ejecuta en x86.

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

 
&ltNUnit Assemblies="Test/bin/$(Platform)/$(Configuration)/Test.dll" Platform="x86" />

(es decir, la prueba TeamCity forma corredor de obligar a 32 bits como en el otro sugerencias)

(Esto incluye cuando la diana plataforma para el conjunto de prueba es Cualquier CPU (aunque, como sucede los he ajustado a x86 explícitamente como algunas pruebas carga de forma dinámica DLL que están restringidas a x86)).

Answer 5

Si se utiliza TeamCity, se puede añadir el teamcity.dotnet.nant.nunit2.platform propiedad con el valor de x 86 a los parámetros de construcción en los ajustes de configuración de su proyecto TeamCity (en la sección Propiedades y variables de entorno).

Answer 6

Tuvo el mismo problema con TeamCity 8.1. Lo que lo resolvió fue cambiar el paso de compilación NUnit .Tiempo de ejecución NET/Plataforma: a x 86

también tuve que cambiar pruebas ejecutadas mediante: camino desde TestProject \ bin \ Release a TestProject \ bin \ x86 \ Release