BadImageFormatException: разрядность DLL или другая причина

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

Не начинайте с разрядности Windows

Операционная система и конкретный процесс — разные уровни проверки. По документации Microsoft о совместимости процессов, 32-битные приложения могут работать в 64-битной Windows. Но 32-битный процесс не загружает 64-битную DLL, а 64-битный — 32-битную. Здесь речь о загрузке нативного компонента в процесс.

Поэтому снимок «у меня Windows x64» не отвечает на вопрос, как запущена программа. Для .NET свойство Environment.Is64BitProcess сообщает, является ли текущий процесс 64-битным. Это ещё не полное название архитектуры: x64 и ARM64 нельзя считать одним и тем же только по этому логическому значению.

Одна надпись DLL не определяет способ подключения

Расширение файла не говорит, является ли он управляемой сборкой, нативной библиотекой или частью комплекта SDK. В описании BadImageFormatException Microsoft приводит несколько причин: в том числе попытку загрузить нативный файл как сборку .NET и использование неподходящего инструмента для сборки.

Там же отдельно рассматриваются reference assembly и исполняемая реализация. Файл для компиляции не следует без проверки подставлять вместо компонента для выполнения. До замены выясните, какой именно файл ожидает код и откуда его должен брать установочный комплект. Совпадение названия не подтверждает совпадение назначения.

Соберите карту загрузки, а не список случайных исправлений

Ниже учебная карта для приложения с внешним SDK. Она показывает, какие доказательства собрать, но не утверждает, что конкретный поставщик использует такую структуру. Начните с реального пути сбойного файла: иначе легко исследовать соседнюю DLL, которая вообще не была загружена.

Почему AnyCPU не делает нативную библиотеку универсальной

Параметр PlatformTarget относится к целевой платформе сборки. Он не перекомпилирует стороннюю нативную DLL и не меняет её требования. Название AnyCPU не означает, что любой процесс сможет загрузить любой вариант внешней библиотеки.

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

Учебный пример: обёртка подходит, а внутренний компонент нет

Предположим, приложение запущено как x64, а поставщик дал управляемую обёртку и нативный компонент x86. Даже если обёртка допускает выполнение в данном процессе, это не делает внутреннюю нативную часть совместимой. Для решения требуется согласованный вариант всей связки, а не переименование каталога с библиотекой.

Возможные направления выбирают по документации SDK: подходящая нативная поставка, согласованная архитектура приложения или отдельный процесс с явным протоколом. Последний вариант — самостоятельная архитектурная работа с обработкой ошибок и доступом к данным. Это не способ незаметно разрешить прямую загрузку несовместимой DLL.

Что проверять, когда разрядность совпадает

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

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

Проверка установочного комплекта по шагам

1. Запишите полное сообщение и место возникновения ошибки. Определите фактический путь файла, который пытались загрузить.
2. Установите архитектуру процесса, тип приложения, среду выполнения и способ запуска. Отдельно отметьте внешний хост, если он есть.
3. Проверьте назначение DLL и рекомендованный поставщиком способ подключения. Не используйте загрузку управляемой сборки для произвольного нативного файла.
4. Сверьте архитектуру и версии нативных частей по всей цепочке, включая компоненты, которые вызывает обёртка.
5. Исправьте конкретное несоответствие в сборке или поставке. Сохраните состав и версии исправленного комплекта.
6. Проверьте согласованный пользовательский сценарий на целевой среде из установленного комплекта, а не только из папки разработчика.

Что не следует делать с рабочей машиной

Не скачивайте одноимённую DLL со случайного сайта и не подменяйте системные файлы. Не отключайте защиту и не запускайте неизвестные компоненты с правами администратора ради проверки гипотезы о разрядности. Эти действия не доказывают совместимость и затрудняют восстановление достоверного состава приложения.

Для Windows-программы согласуйте поддерживаемые платформы и установочные варианты заранее. Если требуется подключение внешнего SDK в автоматизацию рабочего процесса, включите в приёмку именно это действие: например, получение учебного результата через библиотеку, а не один успешный запуск пустого окна.

Итог диагностики должен содержать установленную причину и проверенный комплект. Формулировка «пересобрали в x86, пока работает» слишком слаба, если остальные зависимости и сценарии не проверены. Укажите, что загружалось, почему прежний вариант не подходил и в каких условиях подтверждён исправленный результат.