Не удалось загрузить исключение файла или сборки

Любые мысли о том, что может вызвать это исключение?

У меня есть 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'

Я случайно меняю его значение на "Любой процессор" и забываю его изменить.