BadImageFormatException при загрузке DLL и провайдер не зарегистрирован на локальном компьютере

Question

Я использую приложение .NET 4.0, Доступ к базе данных в 64-битной ОС Windows 7 x 64-разрядная ОС + Office 2010 (64-разрядный совместимый поставщик Microsoft.ACE.OLEDB.12.0).

Цель платформы x86:

• Проблема с провайдером:

  Поставщик «Microsoft.ACE.OLEDB.12.0» не зарегистрирован на локальном компьютере

Целевая платформа x64 или Любой процессор :

• Проблема с DLL-файлом:

  System.BadImageFormatException: не удалось загрузить файл или сборку 'Interop.SHDocVw, версия = 1.1.0.0, культура = нейтральная, PublicKeyToken = null' или одна из ее зависимостей. Предпринята попытка загрузить программу с неверным форматом.

Answer 1

Первую проблему можно решить, установив 32-битную версию провайдера. Скачать можно здесь .

Вторая проблема очень странная, библиотека взаимодействия должна содержать только IL и не зависеть от архитектуры процессора. Когда я создаю Interop DLL из c: \ windows \ system32 \ shdocvw.dll и запускаю CorFlags.exe, я получаю следующее:

Version   : v2.0.50727
CLR Header: 2.5
PE        : PE32
CorFlags  : 1
ILONLY    : 1
32BIT     : 0
Signed    : 0

Обратите внимание, что ILONLY включен, 32BIT выключен. Это должно работать на 64-битной машине просто отлично. Я не близко к одному прямо сейчас, чтобы проверить, попробуйте сами сравнить. Чтобы получить лучший ответ, вы должны задокументировать, какую версию Internet Explorer вы установили и использовали ли вы 64-битную или 32-битную версию DLL для создания взаимодействия. Последний находится в каталоге c: \ windows \ syswow64.

Answer 2

Как я отметил в комментариях, это, вероятно, связано с тем, что ваша эталонная DLL-библиотека является 32-битной.У меня недавно была эта проблема, вы не можете загружать DLL различной битности в один процесс.Чтобы обойти это, в идеале вам нужно выровнять разрядность библиотек DLL.

Если это действительно не вариант, вы можете создать новый процесс для размещения ошибочной библиотеки DLL и упорядочить вызовы при помощиIPC, однако, это далеко не идеально.Я полагаю, что есть также способ объединить библиотеку DLL с другой библиотекой правильной битности, но, вероятно, под капотом снова распределяются межпроцессные вызовы.

В прошлом я успешно использовал IPC длядоступ к 32-битной DLL из 64-битного приложения.К счастью для меня, у маршала не было ничего сложного, это была базовая семантика запроса-ответа.

Answer 3

Вы можете изменить целевую платформу сборки в своем проекте для x86 как временное решение.