Не удалось загрузить файл или сборку или одну из ее зависимостей
У меня есть еще одна из этих проблем "Не удалось загрузить файл или сборку или одну из ее зависимостей".
Дополнительная информация: Не удалось загрузить файл или сборка "Microsoft.Practices.Unity, Версия = 1.2.0.0, Культура = нейтральная, PublicKeyToken = 31bf3856ad364e35 'или одной из его зависимостей. Расположенные определение манифеста сборки не соответствуют ссылочной позиции сборки. (Исключение из HRESULT: 0x80131040)
Я не знаю, что вызывает это или как я могу отладить его, чтобы найти причину.
Я выполнил поиск в каталогах решений .csproj, и каждый раз, когда у меня есть Unity, я:
Ссылка Include = "Microsoft.Practices.Unity, Версия = 2.0.414.0, Культура = нейтральная, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL"
Невозможно найти какую-либо ссылку в любом месте, которая идет против 1.2.0.0 в любом из моих проектов.
Любые идеи, как я должен решить это?
Я также хотел бы узнать, как отлаживать такие проблемы в целом.
Ответы
Ответ 1
-
Проверьте, ссылаетесь ли вы на сборку, которая, в свою очередь, ссылается на старую версию единства. Например, скажем, у вас есть сборка под названием ServiceLocator.dll
, для которой требуется старая версия сборки Unity, теперь, когда вы ссылаетесь на ServiceLocator
, вы должны предоставить ей старую версию Unity, и это создает проблему.
-
Может быть выходной папкой, где все проекты строят свои сборки, имеет старую версию единства.
Вы можете использовать FusLogVw, чтобы узнать, кто загружает старые сборки, просто определите путь для журнала и запустите решение, затем проверьте (в FusLogvw) первую строку, где загружена сборка Unity, дважды щелкните ее и посмотрите на вызывающую сборку, и здесь вы идете.
Ответ 2
Открыть диспетчер IIS
Выберите пулы приложений
затем выберите пул, который вы используете
перейти к расширенным настройкам (с правой стороны)
Измените флаг Включить 32-битное приложение false на true.
Ответ 3
Для меня ни один из других решений не работал (включая стратегию clean/rebuild). Я нашел другое решение для решения проблемы, которое заключается в закрытии и повторной открытии Visual Studio.
Я предполагаю, что это заставляет Visual Studio повторно загружать решение и все проекты, перепроверяя зависимости в процессе.
Ответ 4
Попробуйте очистить папки Debug и Release в вашем решении. Затем удалите и снова добавьте единство.
Ответ 5
При 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
-
Перезапустите ваше приложение!
Ответ 6
После меня работали.
- Удалить временные файлы C:\Windows\Microsoft.NET\Framework\v4.0.30319\Временные файлы ASP.NET
- Закрыть VSTS и снова открыть.
- Удалить и добавить те же DLL (Примечание: вы добавляете одинаковые версии)
Ответ 7
Проверьте файл Web.config/App.config в своем проекте. Проверьте правильность номеров версий.
<bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />
Это сработало для меня.
Ответ 8
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>
Кроме того, вы можете просто обновить корпоративную библиотеку до последней версии.
Ответ 9
Несмотря на то, что исходный вопрос был опубликован 5 лет назад, проблема все еще сохраняется и довольно раздражает.
Общее решение - это тщательный анализ всех ссылочных сборок, чтобы понять, что происходит неправильно. Чтобы упростить эту задачу, я создал инструмент (расширение Visual Studio), который позволяет выбирать сборку.Net(.ddl или.exe файл) и получать график всех ссылочных ассемблеров с прорисованными конфликтующими или пропущенными ссылками.
Этот инструмент доступен в галерее Visual Studio: https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734
Пример вывода: ![enter image description here]()
Ответ 10
У меня была схожая проблема. ** Ответ Juntos правильный **, но вы должны отметить один важный совет!
Для единства 2.1.505.2 указаны различные AssemblyVersion и AssemblyFileVersion:
![enter image description here]()
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?
Ответ 11
В проводнике решений щелкните правой кнопкой мыши по проекту (а не по решению), на вкладке сборки выберите Платформа цели: "Любой процессор".
Ответ 12
Я также получил эту ужасную ошибку и нашел решение для этого...
- Щелкните правой кнопкой мыши по имени решения
- Нажмите "Чистое решение"
- Перезапустить Visual Studio
- Перейти к проекту Свойства → Сборка
- Измените Конфигурация на Отпустить
- Начать отладки (F5)
1), 2)
![Щелкните правой кнопкой мыши по имени решения]()
4), 5)
![Изменить конфигурацию для выпуска]()
Надеюсь, это тоже поможет.
Ответ 13
- Перейти: Решение → Пакет
- Нажмите вкладку Дополнительно (найдите под страницей)
- Добавьте dll к дополнительным сборкам (таким образом мы можем добавить внешние DLL в sharepoint).
Ответ 14
Не уверен, что это может помочь.
Проверьте соответствие имени Assembly и пространства имен Default в свойствах в ваших ассамблях. Это разрешило мою проблему, которая дала ту же ошибку.
Ответ 15
Спасибо Ридди М.
После меня работали.
Удалить временные файлы C:\Windows\Microsoft.NET\Framework\v4.0.30319\Временные файлы ASP.NET
Закрыть VSTS и снова открыть
Удалите и добавьте одни и те же DLL (обратите внимание: вы добавляете одинаковые совпадающие версии)
Ответ 16
В моем случае в папке bin была не ссылочная dll под названием Unity.MVC3, я безуспешно пытался найти любую ссылку на это в visual studio, поэтому мое решение было так просто, как удалить эту DLL из папки bin.
Ответ 17
Вы говорите, что у вас много проектов в вашем решении... ну, начните с одного около вершины порядка сборки. Получите это, чтобы построить, и как только вы это выясните, вы можете применить одно и то же исправление к остальным.
Честно говоря, вам, вероятно, просто нужно обновить свою ссылку. Похоже, что вы либо обновили свою версию, либо не обновили ссылки, либо это относительный путь, если вы держите свое решение в контроле источника. Просто подтвердите свои предположения и повторно добавьте ссылку.
Ответ 18
После меня работали.
- Удалить временные файлы C:\Windows\Microsoft.NET\Framework\v4.0.30319\Временные файлы ASP.NET
- затем щелкните правой кнопкой мыши на Temporary Asp.net Files > properties > security
и дать полный доступ к управлению IIS и всем пользователям, запускающим мой проект.
Ответ 19
Эта проблема произошла со мной, когда одна из моих зависимых библиотек составляла DLL с "Any CPU", когда родительская библиотека ожидала компиляцию "x64".
Ответ 20
Вам нужно удалить файл appname.dll из выходной папки.
Отладка и удаление папок.
Перестройте и скопируйте в файл регенерированной DLL файла.
Ответ 21
I "Установить как проект запуска" незагруженную/необоснованную библиотеку/проект.
Затем развернул его.
Это сработало!
Я думаю, что он не смог найти .dll, потому что он не был в сборке сначала.
Ответ 22
Другая возможная причина: убедитесь, что вы случайно не дали обоим проектам одно и то же имя сборки в свойствах проекта.
Ответ 23
Мое решение для .NET 4.0 с использованием Enterprise Library 5 состояло в том, чтобы добавить ссылку на:
Microsoft.Practices.Unity.Interception.dll
Ответ 24
Следите за противоречивыми ссылками. Даже после чистых и перестроенных противоречивых ссылок все еще будет возникать проблема. Моя проблема заключалась между Афором и Согласием. Я удалил обе ссылки и снова добавил ссылки, переустанавливая конкретную ссылку (в частности, для моего случая, просто для Accord).
Ответ 25
Для меня восстановление игры единства без Unity С# Проверяет Checkmark Checkmark.
Ответ 26
В моем случае ни один из предложенных ответов не работал.
Вот что сработало для меня:
- Удалить ссылку
- Переименовать DLL
- Импортировать ссылку снова
Второй шаг был важен, по-видимому, так как он не работал без него.
Ответ 27
Попробуйте проверить, установлено ли для свойства "Копировать в локальное" значение true, а для конкретной версии установлено значение "Истина". Это относится к приложениям в Visual Studio.
Ответ 28
У меня было это сегодня, и в моем случае проблема была очень странной:
<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>
Изменилось выше и вуаля! Все снова работало.
Ответ 29
У меня была та же проблема, я решил ее с помощью инструкций ниже:
- откройте меню инструментов и выберите опцию
- в настройках окна перейдите в раздел Проекты и решения/Веб-проекты
- проверьте
use the 64bit version of IIS...
![enter image description here]()
Ответ 30
если вы получаете это сообщение об ошибке, открыв приложение на вашем Windows XP, это означает, что сначала вы установили это приложение из-за того, что он не работает без сети 4 и пакета обновления 3. вы установили оба, и снова вы получаете эту ошибку, поэтому вам нужно снова установить это приложение, но сначала удалить из add и remove
Если это не работает, пожалуйста, не злоупотребляйте мной. я также младший