"Була спроба завантажити програму з неправильним форматом", навіть коли платформи однакові

Я викликаю функції з 32-бітної некерованої DLL в 64-бітній системі. Що я отримую:

BadImageFormatException: Була спроба завантажити програму з неправильним форматом. (Виняток з HRESULT: 0x8007000B)

Спочатку у мене були встановлені проекти на платформі Any CPU, тому я змінив їх на x86, але ця помилка все ще виникає. Це дійсно єдиний виправлення, яке я знаю для цього.

DLL-файли не є корумпованими або що-небудь, тому що я можу використовувати їх з іншими програмами (у яких немає джерела). Я думав, що, можливо, це не знаходить залежності, але я перевірив, і вони всі там. Плюс, хіба це не кине DllNotFoundExceptionв цьому випадку?

Що ще можу зробити? І перш ніж ви скажете "Використовуйте 64-бітну некеровану DLL", дозвольте мені зазначити, що її немає. ;)

Якщо ви спробуєте запустити 32-бітні програми на IIS 7 (та / або 64-бітній ОС), ви отримаєте ту ж помилку. Отже, з IIS 7 клацніть правою кнопкою миші по пулу програм і перейдіть до «розширених налаштувань» та змініть «Увімкнути 32-бітні програми» на «ІСТИНА».

Перезавантажте веб-сайт, і він повинен працювати.

Так чи інакше, прапорець " Збірка" в Менеджері конфігурацій було знято для мого виконуваного файлу, тому він все ще працює зі старою будь-якою збіркою процесора. Після того як я це виправив, Visual Studio поскаржився, що не може налагодити збірку, але це було виправлено перезавантаженням.

У візуальній студії клацніть правою кнопкою миші ваш проект -> На лівій панелі натисніть вкладку « Збірка »,

під Platform Target виберіть x86 (або загалом архітектуру, щоб відповідати бібліотеці, до якої ви посилаєтесь)

Я сподіваюся, що це комусь допоможе! :)

У мене теж була ця проблема. Спробували всі пропозиції тут, але вони не допомогли.

Я знайшов ще одну річ, щоб перевірити, що це зафіксувало для мене. У Visual Studio клацніть правою кнопкою миші проект та відкрийте «Властивості». Клацніть на вкладці "Компілювати" (або "Побудувати"), а потім натисніть "Розширені параметри компіляції" внизу.

Перевірте спадне меню "Цільовий процесор". Він повинен відповідати "Платформі", яку ви будуєте. Тобто, якщо ви будуєте "Будь-який процесор", тоді "Цільовий процесор" повинен говорити "Будь-який процесор". Пройдіть усі свої Платформи, зробивши їх активними і перевірте це налаштування.

Якщо ви зіткнулися з цією помилкою, натискаючи зелену кнопку зі стрілкою, щоб запустити додаток, але все-таки хочете запустити додаток у 64 біті. Це можна зробити у VS 2013, 2015, 2017 та 2019 роках

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

Якщо ви використовуєте будь-який процесор , ви можете зіткнутися з цією проблемою, якщо встановлено прапорець 32-бітний параметр "Кращий"

Переконайтесь, що ви зніміть цю опцію в майні проекту Побудови вкладки!

Трохи поза темою для цієї публікації, але пошук цього повідомлення про помилку привів мене сюди.

Якщо ви будуєте командну систему та отримуєте цю помилку, на вкладці процесу визначення збірки є налаштування "Платформа MSBuild". Якщо для цього встановлено значення "Авто", ви можете відчути цю проблему. Змінивши його на "X86", ви також можете усунути помилку.

У моєму випадку я використовував рідну DLL в C #. Ця DLL залежала від кількох інших DLL-файлів, які були відсутні. Після того, як були додані інші DLL-файли, все працювало.

Спираючись на відповідь @paibamboo

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

Мій колега встановив цей прапорець (він явно його шукав), але було повідомлення про помилку. Через кілька годин він зняв прапорець і знову перевірив її. Ось і ось: Код тепер пройшов успішно.

Здається, що є два місця, де збережено стан цього вікна, який вийшов із синхронізації. Зніміть і повторно перевіривши його, синхронізував його ще раз.

Запитання для більш обізнаних користувачів: Чи було оновлення чи щось на минулому тижні (для VS 2015), яке де-синхронізувало штати?

Дивіться також цю відповідь , яка вирішила ту саму проблему для мене.

Опубліковано Луїсом Маком 12.12.2010 о 8:50 Я виявив ту саму проблему, лише для конкретного проекту, коли збирався на 64-бітній машині. Виправлення роботи SEEMS полягає в ручному зміні одного символу в потоці зображень КОЖНОГО ВРЕМЯ, що контролер користувача або форма редагуються в дизайнері

 AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj00LjAuMC4w

Перейти

 AAEAAAD/////AQAAAAAAAAAMAgAAAFdTeXN0ZW0uV2luZG93cy5Gb3JtcywgVmVyc2lvbj0yLjAuMC4w

Це 00LjAuMC4w назад до 0yLjAuMC4w в кінці рядка (00 назад до 0y)

У моєму випадку я використовую крихітний .exe, який перезавантажує посилання DLL за допомогою Reflection. Тож я просто виконую ці кроки, що економить мій день:

З властивостей проекту на Explorer Explorer на вкладці build я вибираю цільову платформу x86

У моєму випадку я проводив тести через MSTest і з'ясував, що я розгортаю і 32-бітну, і 64-бітну DLL в тестову каталог. Програма надала перевагу 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: змініть нижче налаштування для проекту веб-сервісу.