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

Question

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

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

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

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

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

System.BadImageFormatException: Не удалось загрузить файл или сборку
'Spin.TradingServices.DataAcquisition.Test.NUnit, Version = 1.0.12103.2060, Culture = нейтрально, PublicKeyToken = нуль' или один его зависимостей , Была сделана попытка загрузить программу с неправильным форматом . Имя
Файл: 'Spin.TradingServices.DataAcquisition.Test.NUnit, Version = 1.0.12103.2060, Culture = нейтрально, PublicKeyToken = нуль'

сервера трассировки стека: на System.Reflection.RuntimeAssembly._nLoad (AssemblyName имя_файла, строка CodeBase, фактические данные assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & stackMark, булева throwOnFileNotFound, булевы forIntrospection, Boolean suppressSecurityChecks) на System.Reflection.RuntimeAssembly.InternalLoadAssemblyName (AssemblyName assemblyRef, Evidence assemblySecurity, StackCrawlMark & stackMark, Логическое forIntrospection, булева suppressSecurityChecks) на System.Reflection.Assembly.Load (AssemblyName assemblyRef) на NUnit.Core.Builders.TestAssemblyBuilder.Load (String путь) в NUnit.Core.Builders.TestAssemblyBuilder.Build (Строка AssemblyName, Boolean autoSuites) в NUnit.Core.Builders.TestAssemblyBuilder.Build (String AssemblyName, Струнный АСМАП, 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 (Tes tPackage пакет) на NUnit.Core.RemoteTestRunner.Load (TestPackage пакет) на System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage (IntPtr мкр, Object [] арг, сервер объектов, Int32 methodPtr, булева fExecuteInContext, объект [] & outArgs) на System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage (IMessage Сообщ, Int32, Boolean methodPtr fExecuteInContext)

Exception при вызваны повторно [0]: на System.Runtime.Remoting.Proxies. RealProxy.HandleReturnMessage (IMessage reqMsg, IMessage retMsg) в System.Runtime.Remoting.Proxies.RealP Roxy.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. Готово Building Project (цели по умолчанию) " - FAILED

Сложение FAILED

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

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

Answer 1

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

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

Answer 2

У меня была эта проблема с консольным приложением на компьютере X64, , сборка была установлена ​​как x86, и она все еще разбилась. Я зашел в «Свойства на консольном приложении», и в процессе сборки я изменил свою платформу Target с x86 на любой процессор, после чего все тесты работали и успешно выполнялись.

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

Answer 3

Благодаря Ashes999 для меня разбудили.

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

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

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

/process=separate 

или

/process=multiple 

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

Answer 7

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

Answer 8

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

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

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

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

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

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

Бен

Answer 9

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

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

Answer 10

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