Устранение неполадок BadImageFormatException

У меня есть служба Windows, написанная на C # с использованием Visual Studio 2010 и ориентированная на полную .NET Framework 4. Когда я запускаю отладочную сборку, служба работает, как ожидалось. Однако, когда я запускаю его из сборки Release, я получаю System.BadImageFormatException (подробности ниже). Я искал в Интернете решение, но пока все, что я нашел, не помогло мне найти решение.

Проблема существует как в 64-битной Windows 7 (для разработчиков), так и в 32-битной (целевой) Windows XP SP3.

Вот что я пробовал до сих пор:

• Проверенные настройки сборки, такие как Platform Target, одинаковы (x86).
• Используется peverify с параметром / verbose, чтобы убедиться, что двоичные файлы сборки действительны.
• Использует fuslogvw для поиска проблем с загрузкой.
• Используется CheckAsm для поиска недостающих файлов или сборок.

Все эти проверки ничего не меняли. Я включил полный текст информации об исключениях ниже, при этом некоторые имена изменены, чтобы защитить секреты моих корпоративных хозяев.

System.BadImageFormatException не обработан
  Сообщение = Не удалось загрузить файл или сборку «XxxDevices, Версия = 1.0.0.0, Культура = нейтральный, PublicKeyToken = null» или одну из их зависимостей. Была сделана попытка загрузить программу с неправильным форматом.
  Источник = XxxDevicesService
  FileName = XxxDevices, Version = 1.0.0.0, Culture = нейтральный, PublicKeyToken = null
  FusionLog = Менеджер сборки загружается из: C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ clr.dll
Запускается под исполняемым файлом c: \ Dev \ TeamE \ bin \ Release \ XxxDevicesService.vshost.exe
--- Подробный журнал ошибок следует ниже. 

=== Информация о состоянии предварительной привязки ===
ЖУРНАЛ: Пользователь = XXX
ЖУРНАЛ: DisplayName = XxxDevices, версия = 1.0.0.0, культура = нейтральная, PublicKeyToken = null
 (Полностью указано)
ЖУРНАЛ: Appbase = file: /// c: / Dev / TeamE / bin / Release /
ЖУРНАЛ: начальный частный путь = NULL
Вызывающая сборка: XxxDevicesService, версия = 1.0.0.0, культура = нейтральная, PublicKeyToken = null.
===
LOG: эта привязка начинается в контексте загрузки по умолчанию.
ЖУРНАЛ: Использование файла конфигурации приложения: c: \ TeamE \ bin \ Release \ XxxDevicesService.vshost.exe.Config
ЖУРНАЛ: Использование файла конфигурации хоста: 
ЖУРНАЛ: использование файла конфигурации компьютера из C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ config \ machine.config.
ЖУРНАЛ: Политика не применяется к ссылке в настоящее время (частное, настраиваемое, частичное или привязка сборки на основе местоположения).
ЖУРНАЛ: Попытка загрузки нового файла URL: /// c: /TeamE/bin/Release/XxxDevices.DLL.
ОШИБКА: не удалось завершить настройку сборки (hr = 0x8007000b). Зондирование прекращено.

  Трассировки стека:
       в XxxDevicesService.Program.Main (String [] args)
       в System.AppDomain._nExecuteAssembly (сборка RuntimeAssembly, String [] args)
       в Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly ()
       в System.Threading.ExecutionContext.Run (контекст выполнения ExecutionContext, обратный вызов ContextCallback, состояние объекта, логическое значение ignoreSyncCtx)
       в System.Threading.ExecutionContext.Run (контекст выполнения ExecutionContext, обратный вызов ContextCallback, состояние объекта)
       в System.Threading.ThreadHelper.ThreadStart ()
  InnerException: 

Проверенные настройки сборки, такие как Platform Target, одинаковы (x86).

Это не то, о чем говорится в журнале сбоев:

Диспетчер сборок загружается из: C: \ Windows \ Microsoft.NET \ Framework64

Обратите внимание на 64 в названии, это дом 64-разрядной версии фреймворка. Задайте настройку целевой платформы для вашего EXE- проекта, а не для проекта библиотеки классов. Проект XxxDevicesService EXE определяет разрядность процесса.

После того, как я перестал биться головой о стол, думая о той неделе, которую я провел, решая эту проблему, я делюсь тем, что сработало для меня. У меня 64-разрядный 32-разрядный клиент Oracle под Win7, и мой проект MVC 5 настроен для работы на платформе x86 из-за разрядности Oracle. У меня все те же ошибки:

Не удалось загрузить файл или сборку Oracle.DataAccess или одну из ее зависимостей. Была сделана попытка загрузить программу с неправильным форматом.

Я перезагрузил пакеты NuGet, я использовал копии DLL, которые работали для других в разных приложениях, я установил кодовую базу в зависимой сборке так, чтобы она указывала на папку bin моего проекта, я попробовал CopyLocal как true или false, я пробовал все. Наконец, у меня было достаточно работы, я хотел проверить свой код, и как новый подрядчик я не настраивал подрывную деятельность. В поисках способа подключить его к VS, я не нашел ответа. Я обнаружил, что сработал, так это снятие флажка с параметра «Использовать 64-разрядную версию IIS Express для веб-сайтов и проектов» в разделе «Проекты и решения => Веб-проекты» в меню «Инструменты» => «Параметры».

Я обнаружил, что сработал, так это проверка параметра «Использовать 64-разрядную версию IIS Express для веб-сайтов и проектов» в разделе «Проекты и решения => Веб-проекты» в меню «Инструменты» => «Параметры».

Обычно это может произойти, когда вы изменили целевую структуру .csproj и вернули ее к тому, с чего вы начали.

Убедитесь, что 1, если supportedRuntime version = "другая среда выполнения, отличная от цели проекта cs" в теге запуска в app.config.

Убедитесь, что 2 Это также означает проверку других автоматически сгенерированных или других файлов в папке свойств, чтобы увидеть, нет ли несоответствия времени выполнения между этими файлами и файлом, определенным в файле .csproj.

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

У меня была та же проблема, хотя у меня 64-битная Windows 7 и я загружал 64-битную DLL b / c в свойствах проекта | Сборка У меня был установлен флажок «Предпочитать 32-битный». (Не знаю, почему это установлено по умолчанию). Как только я снял этот флажок, все заработало

Вы также можете получить это исключение, если ваше приложение нацелено на .NET Framework 4.5 (например) и у вас есть следующий app.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <startup>
    <supportedRuntime version="v2.0.50727" />
    <supportedRuntime version="v4.0" />
  </startup>
</configuration>

При попытке запустить отладку приложения вы получите исключение BadImageFormatException.

Удаление строки, объявляющей версию v2.0, устранит ошибку.

У меня возникла эта проблема недавно, когда я пытался изменить целевую платформу со старого проекта .NET 2.0 на .NET 4.5.

Задний план

Мы начали получать это сегодня, когда переключили нашу службу WCF с AnyCPU на x64 на сервере Windows 2012 R2 под управлением IIS 6.2.

Сначала мы 10 раз проверили единственную указанную сборку, чтобы убедиться, что это не x86 dll. Затем мы много раз проверяли пул приложений, чтобы убедиться, что он не поддерживает 32-разрядные приложения.

По прихоти я попытался переключить настройку. Оказывается, пулы приложений в IIS по умолчанию имели значение « Включить 32-разрядные приложения», равное False, но IIS по какой-то причине игнорировал его на нашем сервере и всегда запускал нашу службу в режиме x86.

Решение

• Выберите пул приложений.
• Выберите « Установить значения по умолчанию для пула приложений ...» или « Дополнительные настройки ...» .
• Установите для параметра Включить 32-разрядные приложения значение Истина.
• Щелкните ОК .
• Снова выберите « Установить параметры пула приложений по умолчанию ...» или « Дополнительные параметры ...» .
• Установите для параметра Enable 32-Bit Applications значение False.
• Щелкните ОК .

Я исправил эту проблему, изменив веб-приложение для использования другого «Пул приложений».

Для тех, кто может приехать сюда позже .... У меня ничего не работало. Все мои сборки прошли нормально. У меня была конфигурация приложения в одном из моих проектов Visual Studio, которой там не должно было быть. Поэтому убедитесь, что вам нужен файл конфигурации вашего приложения.

Я удалил лишнюю конфигурацию приложения, и она сработала.

Целевая сборка x64 Целевой сервер Хостинг IIS 64 бит

Если сборка приложения ориентирована на 64-разрядную ОС, то на 64-разрядном сервере, на котором размещен IIS, установите для параметра enable 32-bit application в пуле приложений, на котором запущен веб-сайт / веб-приложение, значение false.

Определите пул приложений, используемый приложением, и установите свойство, установив для параметра Включить 32-разрядные приложения значение Истина. Это можно сделать с помощью дополнительных настроек пула приложений.

При создании приложений для 32-разрядной или 64-разрядной платформы (мой опыт работы с Visual Studio 2010) не полагайтесь на Configuration Manager, чтобы установить правильную платформу для исполняемого файла. Даже если CM выбрал x86 для приложения, проверьте свойства проекта (вкладка Build): там все равно может быть написано «Any CPU». И если вы запустите исполняемый файл «Any CPU» на 64-битной платформе, он будет работать в 64-битном режиме и откажется загружать ваши сопутствующие библиотеки DLL, которые были созданы для платформы x86.

Удалите зависимость от System.Runtime в своем Web.Config, у меня это сработало:

<dependentAssembly>
        <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.0.10.0" newVersion="4.0.10.0" />
</dependentAssembly>

Для .NET Core существует ошибка Visual Studio 2017, из-за которой на странице сборки свойств проекта отображается неверная целевая платформа. Как только вы обнаружите, что проблема в том, найти обходные пути довольно просто. Вы можете изменить цель на другое значение, а затем вернуть его обратно.

Как вариант, вы можете добавить идентификатор среды выполнения в .csproj. Если вам нужно, чтобы ваш .exe запускался как x86, чтобы он мог загружать собственную DLL x86, добавьте этот элемент в PropertyGroup:

<RuntimeIdentifier>win-x86</RuntimeIdentifier>

Хорошее место для размещения - сразу после элемента TargetFrameworkили TargetFrameworks.

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

Произошло то, что экземпляр VBCSCompiler.exe каким-то образом застрял и на самом деле не выпускал дескрипторы файлов, чтобы новые экземпляры могли правильно записывать новые файлы, и вызывал проблему. Это стало очевидным, когда я попытался удалить папку «bin», и она жаловалась, что другой процесс использует файлы в ней.

Закрыл VS, открыл диспетчер задач, просмотрел и завершил все экземпляры VBCSCompiler и удалил папку «bin», чтобы вернуться туда, где я был.

Ссылка: https://developercommunity.visualstudio.com/content/problem/117596/vbcscompilerexe-process-stays-runing-after-exiting.html

Для тех, кто может прибыть сюда позже ...
Для решения Desktop у меня есть BadImageFormatExceptionисключение.
Все варианты сборки проекта были в порядке (всеx86 ). Но проект решения StartUp был изменен на какой-то другой проект (проект библиотеки классов).

Изменение проекта StartUp на исходный (проект приложения .exe) было решением в моем случае

Когда я столкнулся с этой проблемой, для меня ее решило следующее:

Я вызывал DLL OpenCV изнутри другого exe, моя dll не содержала уже необходимых dll opencv, таких как highgui, features2d и т.д., доступных в папке моего exe-файла. Я скопировал все это в каталог своего exe-проекта, и он внезапно заработал.

Эта ошибка «Не удалось загрузить файл или сборку« пример »или одну из ее зависимостей. Была сделана попытка загрузить программу с неправильным форматом» обычно вызвана неправильной конфигурацией пула приложений.

1. Убедитесь, что для пула приложений, на котором работает ваш сайт, для параметра «Включить 32-разрядные приложения» установлено значение False.
2. Убедитесь, что вы используете правильную версию для своей платформы.
3. Если вы получаете эту ошибку на веб-сайте, убедитесь, что ваш пул приложений настроен для работы в правильном режиме (сайты версии 3.0 должны работать в 64-битном режиме)
4. Вы также должны убедиться, что ссылка на эту сборку в Visual Studio указывает на правильный файл в папке пакетов.
5. Убедитесь, что у вас установлена ​​правильная версия dll на сайтах GAC для 2.0.
6. Это также может быть вызвано продвижением WSODLibs в веб-проекте.