Nunit.exe не может работать на Vista 64bit, если сборка x86 - PullRequest
27 голосов
/ 16 октября 2008

Я нахожусь на Vista 64 бит, и у меня есть проект, созданный с конфигурацией 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 ...

Трассировка стека серверов: в System.Reflection.Assembly._nLoad (имя_сборки имя_файла, строковое codeBase, доказательство сборкиSecurity, расположение сборкиHint, StackCrawlMark & ​​stackMark, логическое значение throwOnFileNotFound, логическое значение для интроспекции) в System.Reflection.Assembly.InternalLoad (AssemblyName assemblyRef, Evidence AssemblySecurity, StackCrawlMark & ​​stackMark, Boolean forIntrospection) в System.Reflection.Assembly.InternalLoad (строка String AssemblyString, Свидетельство AssemblySecurity, StackCrawlMark & ​​stackMark, логическое значение для интроспекции) в 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 (Строка AssemblyName, Строка testName, Булевы 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 [], сервер объектов, Int32 methodPtr, логический fExecuteInContext, Object [] & outArgs) в System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage (сообщение IMessage, Int32 methodPtr, логическое значение 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) at NUnit.Util.TestLoader.LoadTest (String testName)

Обновление 2

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

Ответы [ 6 ]

52 голосов
/ 16 октября 2008

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

Спасибо за все

5 голосов
/ 16 октября 2008

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

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

4 голосов
/ 03 декабря 2008

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

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

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

(т. Е. Способ запуска теста TeamCity 32-битным, как в других предложениях)

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

0 голосов
/ 02 июня 2014

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

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

0 голосов
/ 27 мая 2011

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

0 голосов
/ 16 октября 2008

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

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

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

...