Усунення несправностей BadImageFormatException

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

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

Ось що я спробував поки що:

• Перевірені параметри збірки, такі як ціль платформи, однакові (x86).
• Використовується Peverify з параметром / verbose, щоб переконатися, що бінарні файли збірки були дійсними.
• Використовує fuslogvw для пошуку будь-яких проблем із завантаженням.
• Використовується CheckAsm для пошуку відсутніх файлів або збірок.

Усі ці перевірки нічого не змінили. Нижче я включив повний текст інформації про виключення, де деякі назви були змінені, щоб захистити секрети моїх корпоративних господарів.

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

=== Попередньо зв’язати інформацію про стан ===
ЛОГ: Користувач = XXX
LOG: DisplayName = XxxDevices, версія = 1.0.0.0, культура = нейтральна, PublicKeyToken = null
 (Повністю вказано)
LOG: Appbase = файл: /// c: / Dev / TeamE / bin / Release /
LOG: Початковий PrivatePath = NULL
Виклик складання: XxxDevicesService, Версія = 1.0.0.0, Культура = нейтральна, PublicKeyToken = null.
===
LOG: Це прив'язка починається в контексті завантаження за замовчуванням.
ЛОГ: Використання файлу конфігурації програми: c: \ TeamE \ bin \ Release \ XxxDevicesService.vshost.exe.Config
LOG: Використання файлу конфігурації хоста: 
ЛОГ: Використання файлу конфігурації машини з C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ config \ machine.config.
LOG: Наразі політика не застосовується для посилання (прив'язка приватної, спеціальної, часткової чи локальної).
LOG: Спроба завантаження нового файлу URL: /// c: /TeamE/bin/Release/XxxDevices.DLL.
ERR: Не вдалося завершити налаштування збірки (hr = 0x8007000b). Зондування припинено.

  StackTrace:
       на XxxDevicesService.Program.Main (Архів String [])
       на System.AppDomain._nExecuteAssembly (збірка RuntimeAssembly, String [] args)
       у Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly ()
       на System.Threading.ExecutionContext.Run (ExecutionContext ExecutionContext, зворотний виклик ContextCallback, стан об'єкта, булева ignoreSyncCtx)
       в System.Threading.ExecutionContext.Run (ExecutionContext ExecutionContext, зворотний виклик ContextCallback, стан об'єкта)
       на System.Threading.ThreadHelper.ThreadStart ()
  InnerException: 

Перевірені параметри збірки, такі як ціль платформи, однакові (x86).

Це не те, що говорить журнал збоїв:

Менеджер збірок завантажується з: C: \ Windows \ Microsoft.NET \ Framework64

Зауважте, що в імені є 64 , це головна частина 64-бітної версії фреймворку. Встановіть на платформі EXE налаштування цільової платформи , а не проект бібліотеки класів. Проект XxxDevicesService EXE визначає швидкість процесу.

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

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

Я перезавантажував пакунки NuGet, використовував копії DLL-файлів, які працювали для інших в різних додатках, я встановлював базу коду у залежній збірці, щоб вказати на папку бін мого проекту, я спробував CopyLocal як істинний чи неправдивий, я спробував усе. Зрештою, мені було ще достатньо зроблено, я хотів перевірити свій код, і як новий підрядник у мене не було налаштовано підривної роботи. Шукаючи способу підключити його до VS, я поцікавився відповіддю. Я виявив, що зняв прапорець "Використовувати 64-бітну версію IIS Express для веб-сайтів і проектів" у розділі Проекти та рішення => Веб-проекти в меню Інструменти => Параметри.

Я виявив, що працював - перевірити параметр "Використовувати 64-бітну версію IIS Express для веб-сайтів та проектів" у розділі Проекти та рішення => Веб-проекти в меню Інструменти => Параметри.

Зазвичай це може статися, коли ви змінили цільовий фреймворк .csproj і повернули його до того, з чого ви почали.

Переконайтеся, що 1, якщо підтримується версіяRuntime version = "інший час виконання від цілі проекту cs" під тегом запуску в app.config.

Переконайтеся, що 2 Це також означає перевірку інших автогенерованих або інших файлів у папці властивостей, щоб побачити, чи немає більше невідповідності між цими файлами і тим, що визначено у файлі .csproj.

Це може просто заощадити багато часу, перш ніж ви почнете пробувати різні речі із властивостями проекту, щоб подолати помилку.

У мене була така ж проблема, хоча у мене 64-розрядна Windows 7, і я завантажував 64-бітний DLL в / в властивості Project | Збірка У мене було перевірено "Віддати перевагу 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 були дефолтом до значення Enable 32-Bit Applications False, але IIS чомусь ігнорував це на нашому сервері і завжди запускав нашу службу в режимі x86.

Рішення

• Виберіть пул додатків.
• Виберіть Set Application Pool Defaults ... або Advanced Settings ... .
• Змініть Увімкнути 32-бітні програми на True.
• Натисніть кнопку ОК .
• Виберіть " Встановити параметри за замовчуванням у пулі додатків ..." або " Додаткові настройки" знову.
• Змініть Увімкнути 32-бітні програми назад на False.
• Натисніть кнопку ОК .

Я вирішив цю проблему, змінивши веб-додаток, щоб використовувати інший "Пул додатків".

Для всіх, хто може приїхати сюди пізніше .... Ніщо не працювало для мене. Всі мої збори були добре. У мене був конфігурація програми в одному з моїх проектів Visual Studio, який не повинен був там бути. Тому переконайтеся, що потрібен ваш конфігураційний файл програми.

Я видалив додатковий конфігурацію додатка, і він працював.

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

Якщо збірка додатків орієнтована на 64-бітну ОС, то на 64-бітному сервері, на якому розміщено IIS, встановіть 32-бітну програму для активації в пулі додатків, на якій працює веб-сайт / веб-додаток, на значення false.

Визначте пул додатків, який використовується програмою, і встановіть властивість, встановивши Включити 32-бітні програми на True. Це можна зробити за допомогою попередніх налаштувань пулу програм.

Створюючи додатки для 32-бітної або 64-розрядної платформи (мій досвід роботи з Visual Studio 2010), не покладайтеся на Менеджер конфігурацій, щоб встановити правильну платформу для виконуваної програми. Навіть якщо у програмі CM вибрано x86 для програми, перевірте властивості проекту (вкладка Build): там все одно може бути написано "Будь-який процесор". І якщо ви запустите «Будь-який процесор», який виконується на 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 був якось застряг і насправді не випускав ручки файлів, щоб дозволити новим екземплярам правильно записати нові файли і викликав проблему. Це стало очевидним, коли я спробував видалити папку "бін", і я скаржився, що інший процес використовує файли там.

Закрив 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 не містив уже потрібних dcl opencv, таких як highgui, features2d і т. Д., Доступних у папці мого файлу EXE. Я скопіював усе це в каталог свого проекту EXE, і це раптом спрацювало.

Ця помилка "Не вдалося завантажити файл або збір" приклад "або одна з його залежностей. Була зроблена спроба завантажити програму з неправильним форматом", як правило, викликана неправильною конфігурацією пулу додатків.

1. Переконайтесь, що для вашого веб-сайту AppPool наразі функція "Увімкнути 32-розрядні програми" встановлена ​​на помилку.
2. Переконайтеся, що ви використовуєте правильну версію для своєї платформи.
3. Якщо ви отримуєте цю помилку на веб-сайті, переконайтеся, що пул додатків налаштований для роботи у правильному режимі (3,0 сайти повинні працювати в 64-бітовому режимі)
4. Ви також повинні переконатися, що посилання на цю збірку у візуальній студії вказує на правильний файл у папці пакунків.
5. Переконайтеся, що у GAC для версії 2.0 встановлена ​​правильна версія dll.
6. Це також може бути спричинено тим, що WSODLibs просувається за допомогою веб-проекту.