System.BadImageFormatException, вызванное проектом NUnit

Добрый день всем. У меня была такая же проблема весь день на работе, и я изо всех сил пытаюсь найти новые пути, чтобы спуститься.

Я получаю следующую ошибку, когда мое решение строится на сервере. У меня нет проблем с запуском/отладкой всех тестов в решении, и он отлично работает. Как сервер, так и мой компьютер - x64. Я следовал советам, которые я нашел безрезультатно.

Я установил Platform Target для x86 для всех проектов в моем решении при всех конфигурациях.

Я знаю, что есть nunit-console-x86.exe, который может иметь значение, но я не уверен, где это указать в коде.

Пожалуйста, поймите, что я проследил интернет, поэтому извиняюсь, если я что-то пропустил.

System.BadImageFormatException: не удалось загрузить файл или сборку
"Spin.TradingServices.DataAcquisition.Test.NUnit, Версия = 1.0.12103.2060, Культура = нейтральная, PublicKeyToken = null или одна его зависимостей. Была сделана попытка загрузить программу с помощью неправильный формат.
Имя файла:" Spin.TradingServices.DataAcquisition.Test.NUnit, Версия = 1.0.12103.2060, Культура = нейтраль, PublicKeyToken = null '

Трассировка стека сервера: в System.Reflection.RuntimeAssembly._nLoad (AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) в System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark & stackMark, Boolean forIntrospection, Boolean suppressSecurityChecks) в System.Reflection.Assembly.Load(AssemblyName assemblyRef) в 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.ConsoleRunner.ConsoleUi.Execute(опции ConsoleOptions) на NUnit.ConsoleRunner.Runner.Main(String [] args)

WRN: Регистрация привязки сборки отключена. Чтобы включить ведение журнала сбоев сбоя, установите значение реестра [HKLM\Software\Microsoft\Fusion! EnableLog] (DWORD) на 1. Примечание: там это некоторое снижение производительности, связанное с сбоем привязки сборки Ведение журнала. Чтобы отключить эту функцию, удалите значение реестра [HKLM\Software\Microsoft\Fusion! EnableLog].

http://app1017-build.oy.gb.sportingindex.com:8080/job/TradingServices.DataAcquisition-Dev/ws/DataAcquisition/build.proj(86,5): ошибка MSB6006: "nunit-console.exe" вышла с кодом -100. Готово Проект строительства " (цели по умолчанию) - FAILED.

Сборка FAILED.

ОБРАТИТЕ ВНИМАНИЕ: Мы вернули нашу сборку на Hudson и теперь переписываем файлы более постепенно. Я расскажу о том, как это происходит. Пробовал получить несколько голов, участвующих в этом, к сожалению, к сожалению. Позор!

Обновление Я еще не вернулся на эту страницу, но похоже, что есть много разных решений. Если бы я мог отметить их всех как ответ, я бы хотел! Те из вас, кто ищет ваш путь сюда, должны, вероятно, дать равный кредит каждому варианту.

Ответ 1

Проверьте версию рамочной версии вашей сборки так же, как и поддержка nUnit test runner. См. RunFile.exe.config для списка поддерживаемых сред выполнения.

Также, если вы настроили с FW 3 на FW 4, у них разное время выполнения (CLR отличается).

Ответ 2

У меня возникла проблема с консольным приложением на компьютере X64, сборка была установлена как x86, и она все еще разбилась. Я перешел в "Свойства на консольном приложении", а в сборке я изменил свою платформу Target с x86 на любой CPU, а затем все тесты работали и успешно выполнялись.

Примечание. Поле платформы Configuration Manager может "лежать" вам и на самом деле не должно отражать то, что на самом деле настроено на свойства проекта. Мой менеджер конфигурации сказал, что "Common.dll" строится как "Любой процессор", но свойства проекта (значение, которое действительно имеет значение) строят его как "x86".

Ответ 3

Небольшое дополнение ко всем ответам. Возможно, вам понадобится изменить платформу бегуна NUnit (Resharper for me), как это было в моем случае. См. Пример

Ответ 4

Я часто сталкиваюсь с этим, когда я тестирую приложение Console или WPF. Несколько причин:

Во-первых, убедитесь, что приложение не запускается в профиле клиента .Net Framework 3 или 4.
Затем сравните целевую платформу .NET-версии как с приложениями, так и с тестовыми проектами. Они должны быть одинаковыми.
Проверить целевую платформу платформы на вкладке сборки. Они должны быть одинаковыми. Например, если в тестовом проекте есть цель " Любой процессор", приложение должно иметь " Любой процессор".

Ответ 5

Убедитесь, что этот параметр правильный: Меню тестирования → Настройки тестирования → Архитектура процессора по умолчанию → x64/x86. Это было неверно в моем случае, и это не удалось с той же проблемой.

Ответ 6

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

Угадайте, что? Это была 32-битная машина. Таким образом, NUnit.exe работает как 32-разрядный (очевидно) и не может понять 64-разрядные тесты.

Решение? Создайте x86 и x64 версию своих тестов и запустите x86 на компьютерах x86 и x64 на машинах x64.

Очевидный. Но стоит проверить.

Ответ 7

Для меня исключение было вызвано недопустимым аргументом /process=single nunit. Если я изменил значение, исключение исчезнет:

/process=separate

или

/process=multiple

p/s: поздний ответ, но только для справки.

Ответ 8

Моя ситуация была немного иной. Ошибка появилась довольно случайно после запуска Unit Test, который был изменен.

Я удалил тест, и ошибка исчезла.

Я воссоздал тест, и ошибка вернулась.

Я переименовал тест, и ошибка исчезла.

Я переименовал тест и проблема не повторилась.

Надеюсь, это поможет!

Бен

Ответ 9

Спасибо Ashes999 за то, что вы меня разбудили.

Эта проблема снова вернулась. И откат и загрузка с помощью не работали. Он оказался объектом монитора, который мы больше не используем. Прокомментировано и исправлено.

Чтобы найти это, выполните Debug All Unit Tests. Исправляйтесь везде, где он останавливается. Если t не приостанавливается, то err.

Ответ 10

Для тех, кто все еще имеет эту проблему, вам также может потребоваться установить поле рамки на тестовом бегуне, чтобы оно соответствовало таковому в вашем включенном проекте (поле справа от ссылки, на которую ссылается AlexM).

В моем случае я писал набор тестов для библиотеки Windows Phone 8, и NUnit не смог правильно определить версию фреймворка, которую он должен использовать.