Ответ 1
Хорошо, я нашел решение на этом веб-сайте. Вы должны использовать \NUnit-2.4.8\bin\nunit-x86.exe вместо\NUnit-2.4.8\bin\nunit.exe... не знали, что у\bin\есть 2 nunit!!
спасибо all
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
Ответы
Ответ 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:
<NUnit Assemblies="Test/bin/$(Platform)/$(Configuration)/Test.dll" Platform="x86" />
(т.е. тестовый бегун 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