Не удалось загрузить исключение файла или сборки
Любые мысли о том, что может вызвать это исключение?
У меня есть webservice proj, когда я загружаю ссылку, я получаю
Не удалось загрузить файл или сборку "Interop.DIB" или одну из его зависимостей. Была сделана попытка загрузить программу с неправильным форматом.
Сведения об исключении: System.BadImageFormatException: Не удалось загрузить файл или сборку "Interop.DIB" или одну из его зависимостей. Была сделана попытка загрузить программу с неправильным форматом.
Внутренние исключения:
[BadImageFormatException: Не удалось загрузить файл или сборку "Interop.DIB" или одну из его зависимостей. Была сделана попытка загрузить программу с неправильным форматом.]
[ConfigurationErrorsException: Не удалось загрузить файл или сборку "Interop.DIB" или одну из его зависимостей. Была сделана попытка загрузить программу с неправильным форматом.]
[HttpException (0x80004005): Не удалось загрузить файл или сборку "Interop.DIB" или одну из его зависимостей. Была сделана попытка загрузить программу с неправильным форматом.]
Информация о версии:
Версия Microsoft.NET Framework: 4.0.30319; Версия ASP.NET: 4.0.30319.272
Ответы
Ответ 1
Хорошо ответ: Got To Start- > Run- > введите inetmgr и левые пулы приложений, выберите DefaultAppPool и имя виртуального каталога приложения, и для обоих убедитесь, что 32-разрядные приложения включены в true, я использую IIS7.0 и Windows 7 64-бит.
![enter image description here]()
Ответ 2
BadImageFormatException
обычно означает 64 против 32-битного конфликта. Одна из сборок установлена на специальную платформу, то есть 64-разрядную или 32-битную, в то время как другая установлена или по умолчанию установлена другая. Убедитесь, что обе сборки предназначены для одной и той же платформы, предпочтительно "Любой процессор". Другими словами, может быть, что 64-битная сборка пытается загрузить 32-разрядную или наоборот.
Это также применимо, если вы вызываете COM или DLL, которые скомпилированы для разных платформ, например, вы вызываете 32-битный COM/DLL из сборки в 64-битной системе, где платформа сборки по умолчанию равна x64. В этом случае скорректируйте свою монтажную платформу.
Чтобы изменить платформу, перейдите в проект Properties → Build → Platform.
Ответ 3
У меня была эта проблема при попытке использовать 64-разрядные DLL файлы в моем проекте ASP.Net в Visual Studio 2013.
Решение заключалось в том, чтобы щелкнуть " Инструменты\Параметры" и пометить это поле:
![enter image description here]()
Ответ 4
Самая распространенная причина в моем опыте заключается в том, что вы внесли изменения в ссылочную сборку, которая требует пересоздания других сборок с использованием этой измененной сборки и не восстанавливала их.
Пример # 1: у вас есть EXE, который ссылается на DLL. Вы добавляете что-то в ссылочную DLL, которая добавляет новый метод, новый параметр, что угодно. Это изменяет внешнюю "подпись" DLL; то есть местоположение в памяти различных точек входа. Вы не восстанавливаете EXE. Когда EXE загружает и пытается ссылаться на новую DLL, ее старая точка входа больше не действительна, поэтому она не может выполнить требуемый код.
Пример # 2: у вас есть x86 EXE, который ссылается на DLL. Эта DLL также должна быть скомпилирована для x86 (или любого CPU). Если вы перестроете его для x64, EXE, работающий в 32-битном пространстве, не поймет инструкции и зарегистрирует ссылки на 64-битный "расширенный" мир и будет плакать дядей.
Ответ 5
У меня была такая же проблема в Visual Studio 2015 в Windows 10 x64. Я уже собирался в любом режиме процессора. Это было приложение MVC4 по умолчанию (ничего не добавлено). Я нашел здесь простое решение, которое сработало для меня:
https://github.com/aspnet/Home/issues/524
В VS 2015:
Инструменты > Параметры > Проекты и решения > Веб-проекты > Используйте 64-разрядную версию IIS Express для веб-сайтов и проектов
Ответ 6
Если бы мне пришлось угадать, это либо: а) не обнаружение сложной сборки, либо б) COM-DLL не зарегистрирована в локальном реестре. Простое копирование DIB в папку /bin недостаточно, если вы обезьяны с COM.
Я считаю, что (B) является наиболее вероятным ответом на то, что происходит.
Ответ 7
Что сработало для меня, так это добавить сборку в GAC. Для этого я выполнил gacutil -i PATH_TO_ASSEMBLY из командной строки Visual Studio
Ответ 8
Я, наконец, обошел это исключение, удалив запись в applicationhost.config для IIS Express (C:\Users {username}\Documents\IISExpress\config\applicationhost.config).
Я также остановил экземпляр IIS express, очищенный и перестроенный в VS. Затем измените конфигурационный файл, а затем перезапустите VS 2013.
Ответ 9
Альтернативой этой проблеме является изменение свойств сборки вашего проекта.
Для vb.net, полученного в Project → Properties → Compile → Advanced Compile Options
Здесь измените целевой процессор
Ответ 10
Что сработало для меня - это обновление BIOS на моей машине!
Ответ 11
Эта работа для меня, если не работает для вас, не голосует. Это невежливо
Поэтому он работает, если я изменяю проект С# с любого CPU на x86 (все dlls скомпилированы в WIN32) из Properties → Build → Platform Target. Я работаю над 64-битным компьютером Win7, и, если я использую Any CPU в качестве цели, он не находит dll-обертки.
https://www.codeproject.com/Questions/358717/Could-not-load-file-or-assembly-dll-file
Ответ 12
Моя ошибка исправлена, с изменением опции сборки:
в моем проекте С#.net win:
Свойства> Сборка> Платформа Target> 'x86'
Я случайно меняю его значение на "Любой процессор" и забываю его изменить.