Не удалось загрузить файл или сборку или одну из ее зависимостей
У меня другая проблема "Не удалось загрузить файл или сборку или одну из ее зависимостей".
Дополнительная информация: Не удалось загрузить файл или сборку "Microsoft.Practices.Unity, версия =1.2.0.0, Culture= нейтральный, PublicKeyToken=31bf3856ad364e35" или одну из ее зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040)
Я понятия не имею, что вызывает это или как я мог отладить это, чтобы найти причину.
Я выполнил поиск в моих каталогах решений.csproj-файлов, и каждый, где у меня есть Unity, у меня есть:
Ссылка Include="Microsoft.Practices.Unity, версия =2.0.414.0, культура = нейтральная, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"
Ни в одном из моих проектов не найдено ни одной ссылки, которая идет вразрез с 1.2.0.0.
Есть идеи, как мне решить эту проблему?
Я также был бы признателен за советы по устранению подобных проблем в целом.
45 ответов
Проверьте, ссылаетесь ли вы на сборку, которая, в свою очередь, ссылается на старую версию Unity. Например, скажем, у вас есть сборка под названием
ServiceLocator.dllкоторой нужна старая версия сборки Unity, теперь, когда вы ссылаетесь наServiceLocatorВы должны предоставить ему старую версию Unity, и это создает проблему.Может быть выходная папка, в которой все проекты строят свои сборки, имеет старую версию unity.
Вы можете использовать FusLogVw, чтобы выяснить, кто загружает старые сборки, просто определить путь для журнала и запустить свое решение, а затем проверить (в FusLogvw) первую строку, в которую загружена сборка Unity, дважды щелкнуть по ней и увидеть вызов сборка, и вот, пожалуйста.
Открыть IIS Manager
Выберите пулы приложений
затем выберите пул, который вы используете
перейти к расширенным настройкам (справа)
Измените флаг Включить 32-битное приложение false на true.
Для меня ни одно из других решений не сработало (включая стратегию очистки / восстановления). Я нашел другое решение, которое заключается в закрытии и повторном открытии Visual Studio.
Я предполагаю, что это вынуждает Visual Studio перезагружать решение и все проекты, перепроверяя зависимости в процессе.
Попробуйте очистить папки Debug и Release в вашем решении. Затем удалите и добавьте единство снова.
Несмотря на то, что первоначальный вопрос был опубликован 5 лет назад, проблема все еще сохраняется и довольно раздражает.
Общее решение - тщательный анализ всех сборок, на которые ссылаются, чтобы понять, что происходит не так. Чтобы упростить эту задачу, я создал инструмент (расширение Visual Studio), который позволяет выбирать сборку.Net (файл.ddl или.exe) и получать график всех сборок, на которые имеются ссылки, с выделенными конфликтующими или пропущенными ссылками.
Инструмент доступен в галерее Visual Studio: https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734
Пример вывода: 
При 99% не удалось загрузить файл или сборку, или одна из проблем с зависимостями вызвана зависимостями! Я предлагаю вам выполнить следующие шаги:
Загрузите Dependency Walker с http://www.dependencywalker.com/
Запустите Dependency Walker и откройте dll (в моем случае
NativeInterfaces.dll)Вы можете увидеть один или несколько DLL с ошибкой в красном Ошибка открытия файла...
Это означает, что эта DLL отсутствует в вашей системе; в моем случае имя dll
MSVCR71.DLLВы можете скачать скучающие DLL из Google и скопировать в правильном пути (в моем случае
c:\windows\system32)На этом этапе вы должны зарегистрировать новый dll в GAC (Global Assembly Cache): откройте терминал DOS и напишите:
cd \Windows\System32 regsvr32 /i msvcr71.dllПерезапустите ваше приложение!
Следующее сработало для меня.
- Удалите временные файлы C:\Windows\Microsoft.NET\Framework\v4.0.30319\ Временные файлы ASP.NET
- Закройте VSTS и снова откройте
- Удалите и добавьте одинаковые библиотеки DLL (Примечание: вы добавляете одинаковые совпадающие версии)
Microsoft Enterprise Library (на которую ссылается.NetTiers) была нашей проблемой, которая в свою очередь ссылалась на более старую версию Unity. Для решения этой проблемы мы использовали следующее перенаправление привязки в файле web.config:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Practices.Unity.Configuration" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Кроме того, вы можете просто обновить Enterprise Library до последней версии.
В обозревателе решений щелкните правой кнопкой мыши проект (не решение), на вкладке "Сборка" выберите "Цель платформы": "Любой процессор".
Проверьте файл Web.config/App.config в вашем проекте. Проверьте, правильны ли номера версий.
<bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />
Это сработало для меня.
У меня была похожая проблема. ** Ответ Juntos правильный **, но вы должны отметить один важный совет!
Для единицы 2.1.505.2 указываются разные AssemblyVersion и AssemblyFileVersion:
AssemblyFileVersion используется nuget, но CLR не заботится об этом! CLR собирается использовать только AssemblyVersion!
Таким образом, перенаправления должны применяться к версии, указанной в AssemblyVersion: 2.1.505.0
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>
См. Также: Каковы различия между AssemblyVersion, AssemblyFileVersion и AssemblyInformationalVersion?
Я также получил эту ужасную ошибку и нашел решение для этого...
- Щелкните правой кнопкой мыши по названию решения.
- Нажмите Чистое решение
- Перезапустите Visual Studio
- Перейти к проекту Свойства >> Построить
- Изменить конфигурацию на выпуск
- Начать отладку (F5)
1), 2)
4), 5)
Надеюсь, это поможет вам тоже.
У меня была та же проблема, я решил ее с помощью инструкций ниже:
- откройте меню инструментов и выберите опцию
- в настройках окна перейдите в раздел Проекты и решения / Веб-проекты
- проверить
use the 64bit version of IIS ...
Не уверен, что это может помочь.
Убедитесь, что имя сборки и пространство имен по умолчанию в свойствах ваших сборок совпадают. Это решило мою проблему, которая привела к той же ошибке.
- Перейти:Решение -> Пакет
- Нажмите на вкладку " Дополнительно" (найдите под страницей)
- Добавьте вашу dll к дополнительным сборкам (таким образом мы можем добавить внешние dll в sharepoint).
В моем случае в папке bin была не ссылочная DLL-библиотека под названием Unity.MVC3, я безуспешно пытался найти любую ссылку на нее в Visual Studio, поэтому мое решение было так просто, как удалить эту DLL из папки bin.
Спасибо Риддхи М. Следующее сработало для меня.
Удалите временные файлы C:\Windows\Microsoft.NET\Framework\v4.0.30319\ Временные файлы ASP.NET Закройте VSTS и снова откройте Удалить и добавить те же библиотеки DLL (Примечание: вы добавляете одинаковые совпадающие версии)
Пытался закрыть и снова открыть VS, как было предложено, но это не сработало.
Мне пришлось перейти с СМЕШАННЫХ ПЛАТФОРМ на ЛЮБОЙ ЦП .
Следующее сработало для меня.
- Удалите временные файлы C:\Windows\Microsoft.NET\Framework\v4.0.30319\ Временные файлы ASP.NET
- затем щелкните правой кнопкой мыши Временные файлы Asp.net> свойства> безопасность и предоставьте полный контроль доступа к IIS и всем пользователям, выполняющим мой проект
У меня было это сегодня, и в моем случае проблема была очень странной:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.1.0" newVersion="3.1.0.0" />
</dependentAssembly>0.
Обратите внимание на случайные символы в конце XML - так или иначе они были перенесены из номера версии в конец этого блока XML!
<dependentAssembly>
<assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.1.0.0" newVersion="3.1.0.0" />
</dependentAssembly>
Поменял на вышесказанное и вуаля! Все снова заработало.
Если вы получаете это сообщение об ошибке при открытии приложения в Windows XP, это означает, что вы сначала установили это приложение, так как оно не работает без net framework 4 и пакета обновления 3 . Вы установили оба, и снова вы получаете эту ошибку, поэтому вы должны переустановить это приложение снова, но сначала удалить из добавить и удалить
если это не работает, пожалуйста, не злоупотребляйте мной. я тоже младший
Эта проблема произошла со мной, когда одна из моих зависимых библиотек компилировала DLL с "Any CPU", когда родительская библиотека ожидала компиляцию "x64".
Вы говорите, что в вашем решении много проектов... ну, начните с одного в верхней части порядка сборки. Получите это, чтобы построить, и как только вы выясните это, вы можете применить то же самое исправление к остальным.
Честно говоря, вам, вероятно, просто необходимо обновить вашу ссылку. Похоже, вы либо обновили свою версию и не обновили ссылки, либо это проблема относительного пути, если вы держите свое решение в системе контроля версий. Просто подтвердите свои предположения и повторно добавьте ссылку.
Я "Сделать стартовым проектом" выгруженную / найденную библиотеку / проект.
Затем развернул его.
Это сработало!
Я думаю, что он не смог найти.dll, потому что он не был в сборке вначале.
Ищите противоречивые ссылки. Даже после очистки и перестройки конфликтующие ссылки все равно будут вызывать проблемы. Моя проблема была между AForge и Accord. Я удалил обе ссылки и заново добавил ссылки, перевыбрав конкретную ссылку (в моем случае, только Accord).
Попробуйте проверить, установлено ли для свойства "Copy to Local" для ссылки значение true, а для конкретной версии установлено значение true. Это актуально для приложений в Visual Studio.
Другая возможная причина: убедитесь, что вы случайно не дали обоим проектам одно и то же имя сборки в свойствах проекта.
Очистите решение, затем щелкните проект правой кнопкой мыши и выберите Package
Здесь увеличивают Assembly а также Assembly file версия и пересборка.
Если это не сработает,
1 - Откройте решение в проводнике.
2 - Закройте Visual Studio.
3 - Удалить все bin а также obj папки.
4 - Повторно откройте проект и соберите его.
Моим решением для.NET 4.0 с использованием Enterprise Library 5 было добавить ссылку на:
Microsoft.Practices.Unity.Interception.dll
Вы должны удалить файл appname.dll из выходной папки. Очистка папок Debug и Release. Перестройте и скопируйте в выходную папку восстановленный файл DLL.