visual studio microsoft español descargar community c# .net .net-2.0 nunit 64bit

c# - studio - Nunit.exe no puede funcionar en Vista 64bits si x86 build



visual studio installer (6)

Ok, encontré la solución en este sitio web . Tienes que usar / 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

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 .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?

Actualizar

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

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

Rastreo de la pila del servidor: en System.Reflection.Assembly._nLoad (AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark y stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection) en System.Reflection.Assembly.InternalLoad (AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark y stackMark, Boolean forIntrospection) en System.Reflection.Assembly.InternalLoad (String assemblyString, Evidence assemblySecurity, StackCrawlMark & ​​stackMark, Boolean forIntrospection) en System.Reflection.Assembly.Load (String assemblyString) en NUnit.Core.Builders.TestAssemblyBuilder.Load (String ruta) 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 [] y outArgs) en System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage (mensaje de IMessage, Int32 methodPtr, booleano fExecuteInContext)

Excepción reiniciada 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. TestRunner.Load (paquete TestPackage) en NUnit.Util.TestDomain.Load (paquete TestPackage) en NUnit.Util.TestLoader.LoadTest (String testName)

Actualización 2

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


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

Me imagino que cuando cargues NUnit estará construido con la opción Any CPU, así 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.

Trataría de cambiar todas las configuraciones a Cualquier CPU y ver si esto resuelve tu problema.


Es probable que el host de NUnit se ejecute 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.

Puede intentar ejecutar corflags en el ejecutable NUnit para forzarlo a ejecutar x86, usando la bandera / 32bit +


Esto también puede ocurrir cuando se actualiza de TeamCity 3.1 a 4.0 en un servidor de compilación x64 con la Plataforma de ejecución de MSBuild configurada 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, el primer arreglo que funcionó fue agregar una anulación de plataforma a la llamada NUnit en mi script MSBuild:

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

(es decir, la manera en que el corredor de prueba TeamCity forzó 32 bit como en las otras sugerencias)

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


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 TeamCity (en la sección Variables de propiedades y entorno).


Tuve el mismo problema con TeamCity 8.1. Lo que lo resolvió fue cambiar NUnit build step .NET Runtime / Platform: a x86

También tuve que cambiar las pruebas de ejecución desde: ruta desde TestProject / bin / Release a TestProject / bin / x86 / Release