Подтвердить что ты не робот

Nunit.exe не может работать с Vista 64bits, если сборка x86

Я на 64-разрядной версии Vista, и у меня есть проект, построенный с конфигурацией x86. Все работает нормально. Теперь мы в то время создаем тест. У нас есть NUnit 2.4.8, но у нас много проблем.

Тест загружается через Nunit.exe(gui), когда мы напрямую выбираем .dll, но при выполнении мы имеем system.badimageformatexception.

Я прочитал, обыскав Google несколько трюков о nunit.exe.config, но никто не работает. (переход на UTF8... uncomment.net для запуска).

Любая идея?

Обновление

Я очистил решение и удалю всю папку BIN. Теперь, когда я компилирую, я ясно вижу, что у меня есть только/x86/в каталоге bin, а не в old/debug/, который был в x64.

Когда я иду с Nunit, у меня есть исключение (при загрузке): System.IO.FileNotFoundException...

Трассировка стека сервера:  в System.Reflection.Assembly._nLoad (AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark & stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)  в System.Reflection.Assembly.InternalLoad(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark & stackMark, Boolean forIntrospection)  в System.Reflection.Assembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark & stackMark, Boolean forIntrospection)  в System.Reflection.Assembly.Load(String assemblyString)  в NUnit.Core.Builders.TestAssemblyBuilder.Load(String path)  в NUnit.Core.Builders.TestAssemblyBuilder.Build(String assemblyName, Boolean autoSuites)  в NUnit.Core.Builders.TestAssemblyBuilder.Build(String assemblyName, String testName, Boolean autoSuites)  в NUnit.Core.TestSuiteBuilder.BuildSingleAssembly(пакет TestPackage)  в NUnit.Core.TestSuiteBuilder.Build(пакет TestPackage)  в пакете NUnit.Core.SimpleTestRunner.Load(пакет TestPackage)  в пакете NUnit.Core.ProxyTestRunner.Load(пакет TestPackage)  в пакете NUnit.Core.ProxyTestRunner.Load(пакет TestPackage)  в NUnit.Core.RemoteTestRunner.Load(пакет TestPackage)  в System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage (IntPtr md, Object [] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object [] & outArgs)  в System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Исключение, сброшенное в [0]:  в System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)  в System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData & msgData, Int32-тип)  в пакете NUnit.Core.TestRunner.Load(пакет TestPackage)  в NUnit.Util.TestDomain.Load(пакет TestPackage)  в NUnit.Util.TestLoader.LoadTest(String testName)

Обновление 2

Я компилирую с ЛЮБОГО ЦП, который я изменил, чтобы быть x86 вместо x64. Причина заключается в debug. Это уже обсуждалось в предыдущей ссылке. Я должен подтвердить, что NUnit работает в режиме 64 бит и Corflags.exe

4b9b3361

Ответ 1

Хорошо, я нашел решение на этом веб-сайте. Вы должны использовать \NUnit-2.4.8\bin\nunit-x86.exe вместо\NUnit-2.4.8\bin\nunit.exe... не знали, что у\bin\есть 2 nunit!!

спасибо all

Ответ 2

Хост NUnit, скорее всего, работает как 64-битный процесс (вы можете подтвердить это, посмотрев в диспетчере задач). Если вы собираете только x86, тогда он не сможет работать в этом процессе.

Вы можете запустить corflags в исполняемом файле NUnit, чтобы заставить его запускать x86, используя флаг /32bit +

Ответ 3

Это также может произойти при обновлении с TeamCity 3.1 до 4.0 на сервере сборки x64 с платформой запуска MSBuild, установленной на x86. Бегун TeamCity, по-видимому, по-разному использует платформу в 4.0, чем 3.1, не считая того, что в сборке работает x86.

В моем случае первое исправление, которое работало, заключалось в добавлении переопределения платформы к вызову NUnit в моем MSBuild script:

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

(т.е. тестовый бегун TeamCity для форсирования 32 бит, как и в других предложениях)

(Сюда относится, когда целевой платформой для тестовой сборки является любой CPU (хотя, как это бывает, я установил их на x86 явно, поскольку некоторые тесты динамически загружают DLL, которые ограничены x86)).

Ответ 4

Почему вы используете конфигурацию x86, а не какой-либо CPU?

Я бы предположил, что когда вы загружаете NUnit, он был построен с опцией Any CPU, поэтому JITs на x64-код. Когда это пытается загрузить ваши тесты, которые специально скомпилированы для запуска в качестве x86, он генерирует исключение.

Я бы попробовал изменить все ваши настройки конфигурации на любой CPU и посмотреть, разрешает ли это ваша проблема.

Ответ 5

Если вы используете TeamCity, вы можете добавить свойство teamcity.dotnet.nant.nunit2.platform со значением x86 в параметры сборки в настройках конфигурации проекта TeamCity ( в разделе "Свойства и переменные среды" ).

Ответ 6

Была та же проблема с TeamCity 8.1. Решено было изменить шаг сборки NUnit .NET Runtime/ Платформа: до x86

Мне также пришлось изменить Запустить тесты: из TestProject\bin\Release в TestProject\bin\x86\Release