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

Question

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

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

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

Есть какие-нибудь идеи?

Обновить

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

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

Трассировка стека сервера:в системе.Размышление.Сборка._nLoad(имя файла AssemblyName, Строковая кодовая база, Доказательство безопасности сборки, Местоположение сборки, StackCrawlMark& stackMark, Логическое значение throwOnFileNotFound, Логическое значение forIntrospection) в системе.Отражение.Сборка.Внутренняя загрузка (AssemblyName AssemblyRef, Evidence assemblySecurity, StackCrawlMark & stackMark, логический предварительный просмотр) в системе.Отражение.Сборка.Внутренняя загрузка (строка assemblyString, доказательство assemblySecurity, StackCrawlMark & stackMark, логический предварительный просмотр) в системе.Отражение.Сборка.Загрузка (строка assemblyString) в NUnit.Core.Builders.TestAssemblyBuilder.Load(путь к строке) в NUnit.Core.Builders.TestAssemblyBuilder.Сборка (строковое имя сборки, логические автозамены) в NUnit.Core.Builders.TestAssemblyBuilder.Сборка (строковое имя сборки, строковое тестовое имя, логические автозамены) в NUnit.Core.TestSuiteBuilder.BuildSingleAssembly (тестовый пакет) в NUnit.Core.TestSuiteBuilder.Сборка (тестовый пакет) в NUnit.Core.SimpleTestRunner.Load (тестовый пакет) в NUnit.Core.ProxyTestRunner.Load (тестовый пакет) в NUnit.Core.ProxyTestRunner.Load (тестовый пакет) в NUnit.Core.RemoteTestRunner.Load (тестовый пакет) в System.Runtime.Удаленное взаимодействие.Обмен сообщениями.StackBuilderSink._PrivateProcessMessage(IntPtr md, аргументы Object[], сервер объектов, метод Int32ptr, Логический fExecuteInContext, Object[]и исходные аргументы) в системе.Время выполнения.Удаленное взаимодействие.Обмен сообщениями.StackBuilderSink.SyncProcessMessage(сообщение iMessage msg, Int32 methodPtr, логический fExecuteInContext)

Исключение повторно генерируется в [0]:в System.Runtime.Удаленное подключение.Прокси.RealProxy.Обработчик обратного сообщения (iMessage reqMsg, iMessage retMsg) в System.Runtime.Удаленный доступ.Прокси.RealProxy.PrivateInvoke (MessageData & msgData, тип Int32) в NUnit.Core.TestRunner.Load (тестовый пакет) в NUnit.Util.TestDomain.Load (тестовый пакет) в NUnit.Util.TestLoader.LoadTest(строковое имя теста)

Обновление 2

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

Answer 1

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

Спасибо всем

Answer 2

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

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

Answer 3

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

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

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

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

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

Answer 4

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

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

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

Answer 5

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

Answer 6

Была такая же проблема с TeamCity 8.1.Что решило проблему, так это изменение шага сборки NUnit Среда выполнения .NET / Платформа: Для x86

Мне тоже пришлось измениться Запускайте тесты из: путь от Тестовый проект\bin elease Для Тестовый проект\bin\x86 elease