«Была предпринята попытка загрузить программу с неверным форматом», даже если платформы одинаковы

Я вызываю функции из 32-разрядной неуправляемой библиотеки DLL в 64-разрядной системе. Что я получаю это:

BadImageFormatException: была предпринята попытка загрузить программу с неверным форматом. (Исключение из HRESULT: 0x8007000B)

Сначала мои проекты были настроены на платформу Any CPU, поэтому я изменил их оба на x86, но эта ошибка все еще происходит. Это действительно единственное исправление, которое я знаю для этого.

DLL не повреждены или что-то еще, потому что я могу использовать их с другими программами (для которых у меня нет источника). Я подумал, что, возможно, он не нашел зависимости, но я проверил, и все они там. Плюс, не бросит ли это DllNotFoundExceptionв этом случае?

Что еще я могу сделать? И прежде чем вы скажете: «Вместо этого используйте 64-разрядную неуправляемую DLL», позвольте мне отметить, что ее нет. ;)

Если вы попытаетесь запустить 32-разрядные приложения на IIS 7 (и / или на компьютере с 64-разрядной ОС), вы получите ту же ошибку. Итак, в IIS 7 щелкните правой кнопкой мыши пул приложений приложений и перейдите в раздел «Дополнительные параметры» и измените «Включить 32-разрядные приложения» на «ИСТИНА».

Перезапустите ваш сайт, и он должен работать.

Каким-то образом флажок Build в Configuration Manager был снят для моего исполняемого файла, поэтому он все еще работал со старой сборкой Any CPU. После того, как я это исправил, Visual Studio пожаловалась, что не может отладить сборку, но это было исправлено путем перезапуска.

В Visual Studio щелкните правой кнопкой мыши свой проект -> На левой панели перейдите на вкладку Build ,

в разделе Platform Target выберите x86 (или, в более общем случае, архитектуру, соответствующую библиотеке, на которую вы ссылаетесь)

Я надеюсь, что это помогает кому-то! :)

У меня тоже была эта проблема. Перепробовал все предложения здесь, но они не помогли.

Я нашел другую вещь, чтобы проверить, что исправило это для меня. В Visual Studio щелкните правой кнопкой мыши проект и откройте «Свойства». Нажмите на вкладку «Компиляция» (или «Сборка»), а затем нажмите «Дополнительные параметры компиляции» внизу.

Проверьте выпадающий список «Target CPU». Он должен соответствовать «Платформе», которую вы строите. То есть, если вы создаете «Любой процессор», тогда «Целевой процессор» должен сказать «Любой процессор». Просмотрите все свои платформы, сделав их активными, и проверьте этот параметр.

Если вы столкнулись с этой ошибкой, когда нажимаете зеленую кнопку со стрелкой, чтобы запустить приложение, но по-прежнему хотите запустить приложение в 64-разрядной версии. Вы можете сделать это в VS 2013, 2015, 2017 и 2019

Перейдите: Инструменты> Параметры> Проекты и решения> Веб-проекты> Использовать 64-разрядную версию IIS Express

Если вы используете любой ЦП , вы можете столкнуться с этой проблемой, если установлен флажок Предпочитать 32-разрядный :

Убедитесь, что вы сняли этот флажок на вкладке Build свойства проекта !

Немного не по теме для этого поста, но поиск этого сообщения об ошибке привел меня сюда.

Если вы собираете систему через систему Team и получаете эту ошибку, вкладка процесса определения сборки имеет параметр «MSBuild Platform». Если для этого параметра установлено значение «Авто», вы можете столкнуться с этой проблемой. Изменение его на «X86» также может устранить ошибку.

В моем случае я использовал нативную DLL в C #. Эта DLL зависела от нескольких других отсутствующих DLL. Как только эти другие библиотеки были добавлены, все работало.

Опираясь на ответ @paibamboo

Он сказал: Перейти к: Инструменты> Параметры> Проекты и решения> Веб-проекты> Использовать 64-разрядную версию IIS Express

Мой коллега проверил этот флажок (он явно искал его), но имел сообщение об ошибке в вопросе. Через несколько часов он снял флажок и снова проверил. И вот, код теперь работает с успехом.

Похоже, что есть два места, где состояние этого ящика не сохранено, которое стало не синхронизированным. Отпроверка и повторная проверка синхронизировались снова.

Вопрос для более знающих пользователей: было ли обновление или что-то на прошлой неделе (для VS 2015), которые отменили синхронизацию состояний?

Также посмотрите этот ответ , который решил ту же проблему для меня.

Написал Luis Mack 5/12/2010 в 8:50 AM Я обнаружил ту же проблему, только для конкретного проекта при компиляции на 64-битной машине. Исправление, которое SEEMS работает, состоит в том, чтобы вручную изменять один символ в потоке изображения КАЖДЫЙ РАЗ, когда пользовательский контроль или форма редактируются в конструкторе.

 AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w

Изменить на

 AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w

То есть 00LjAuMC4w обратно в 0yLjAuMC4w в конце строки (00 назад в 0y)

В моем случае я использую крошечный .exe, который перезагружает ссылочные библиотеки DLL через Reflection. Так что я просто делаю эти шаги, которые спасают мой день:

Из свойств проекта в обозревателе решений на вкладке «Сборка» я выбираю целевой платформу от x86

В моем случае я выполнял тесты через MSTest и обнаружил, что развертываю 32-битную и 64-битную DLL в каталог test. Программа отдавала предпочтение 64-битной DLL и вызывала ее сбой.

TL; DR Убедитесь, что в тестах используются только 32-битные библиотеки DLL.

У нас была похожая проблема, и нам удалось ее исправить, установив целевую платформу на x86.

Я решил эту проблему способом «Windows». После проверки всех моих настроек, очистки решения и его восстановления я просто закрыл решение и снова открыл его. Тогда это сработало, поэтому VS, вероятно, не избавился от некоторых вещей во время уборки. Когда логические решения не работают, я обычно обращаюсь к нелогичным (или, казалось бы, нелогичным). Windows не подводит меня. :)

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

Я дважды щелкнул .exe, чтобы посмотреть, что произойдет, и он сказал мне установить 4.5 ....

Так что я понизился до 4.0, и это сработало!

Поэтому убедитесь, что ваши версии совпадают. Он отлично работал на моем устройстве dev, но на сервере была более старая версия .NET.

В моем случае это было неправильное содержание файла. DLL была загружена из Интернета, но содержимое DLL было HTML-страницей: D Попробуйте проверить, является ли это двоичным файлом, если он кажется правильным DLL :)

У нас была такая же проблема в ядре .NET. Решение состояло в том, чтобы загрузить 32-разрядную среду выполнения .netcore и получить цель вашего проекта.x86

В вашем csprojфайле добавьте

  <PropertyGroup>
    <PlatformTarget>x86</PlatformTarget>  
  </PropertyGroup>

  <PropertyGroup>
    <RunCommand Condition="'$(PlatformTarget)' == 'x86'">$(MSBuildProgramFiles32)\dotnet\dotnet</RunCommand>    
  </PropertyGroup>

Это использовалось для компьютера с Windows, вам нужно будет настроить пути и так далее для Linux / OSX

Если вы импортируете неуправляемую DLL, используйте

CallingConvention = CallingConvention.Cdecl 

в вашем методе импорта DLL.

1: Перейдите: Инструменты> Параметры> Проекты и решения> Веб-проекты> Использовать 64-разрядную версию IIS Express 2: измените настройки ниже для проекта веб-службы.