BadImageFormatException при загрузке 32-битной DLL, цель - x86

Question

У меня есть DLL (FreeType), которая, безусловно, 32-битная (заголовок: IMAGE_FILE_MACHINE_I386).

Я хочу использовать ее из кода C #, используя DllImport.

Цель моего приложенияэто x86, IntPtr.Size это 4, процесс 32-битный.

Но я получаю BadImageFormatException (исключение из HRESULT: 0x8007000B).Что может быть не так?

Конечно, я использую 64-битную Windows 7.

Answer 1

Из того, что я понимаю, сборка, специально созданная для x86 и работающая в 64-разрядной операционной системе, может загружать только библиотеки, созданные для x86, иначе будет выдано исключение BadImageFormatException. В 64-разрядной ОС сборка, созданная для Any CPU или x64, выдает то же исключение при попытке загрузить библиотеку x86.

Итак, предполагая, что ничего невероятно странного не происходит, я бы позаботился о том, чтобы вы настроили приложение для сборки под x86, открыв свойства проекта и щелкнув по вкладке «Сборка». Убедитесь, что для параметра «Platform Target» установлено значение «x86», а не «Любой ЦП».

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

Answer 2

Перекомпилируйте dll с опцией «Любой процессор» в Build -> Platform.

Answer 3

ОК, похоже на ложное предупреждение. Это не было связано с битностью, просто отсутствовала другая DLL, от которой зависит тип freetype. Однако сообщения об ошибках могут быть более полезными.

Answer 4

Получена та же ошибка при вызове 64-битного C Dll из C #. Мне пришлось вручную изменить C # Properties->Build->Platform target с Any Cpu на x64. Видимо Any Cpu иногда бывает NoCpu.

Answer 5

Кроме того, для веб-приложения необходимо разрешить запуск 32-разрядных приложений в IIS 7. См. http://www.fishofprey.com/2009/04/badimageformatexception-in-iis-70-on-64.html

Answer 6

Я подозреваю, что общая причина этого исключения изменилась за 8 лет, с тех пор как вопрос был впервые задан. На моей установке с использованием VS 2017 я обнаружил, что снятие флажка «Предпочитать 32-разрядный» решило проблему:

Снимите флажок «Предпочитать 32-битный» в параметрах сборки

Это заставило мою 64-битную DLL, собранную из C ++, загружаться правильно. И наоборот, проверка этой опции должна приводить к корректной загрузке 32-битных DLL.

Answer 7

У меня была похожая ошибка. Я мог бы решить это, добавив ucrtbase.dll или ucrtbased.dll для отладки, а также vcruntime140.dll или vcruntime140d.dll для отладки в каталог исполняемого файла. Я думаю, что 140 зависит от номера версии Visual Studio, которую вы используете.

ucrtbase.dll обычно лежит в C:\Windows\System32. vcruntime140.dll лежит в C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x86\vcruntime140.dll

Вы можете найти больше информации здесь: http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

Answer 8

вы используете Свойства в проекте C # и изменяете "Цель платформы" на x64. введите описание изображения здесь

Answer 9

Когда вы создаете собственное приложение / DLL что-то с помощью Visual Studio, оно получает зависимость от «распространяемого» пакета для этой версии Visual Studio. Он содержит библиотеки DLL, такие как msvcr100.dll и msvcp100.dll (для различных значений 100).

В моем случае я видел эти библиотеки DLL в каталоге Windows/system32 целевого компьютера, поэтому я подумал, что все в порядке. Оказывается, эти DLL были x64! Я понятия не имею, почему каталог с именем system32 содержит 64-разрядные библиотеки DLL. Поэтому я искал в каталоге Visual Studio 2010 все, что имело имя msvc*.dll, и обнаружил x86-версии msvcr100.dll и msvcp100.dll. Я скопировал их на целевой компьютер (в месте, доступном из пути моей программы), и все было хорошо.

Надеюсь, это поможет кому-то еще столкнуться с явным безумием Microsoft.

Answer 10

Вы можете попробовать проверить опцию «Свойства» -> «Построить» -> «Разрешить небезопасный код».