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

У меня есть еще одна из этих проблем "Не удалось загрузить файл или сборку или одну из ее зависимостей".

Дополнительная информация: Не удалось загрузить файл или сборка "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% не удалось загрузить файл или сборку, или одна из проблем с зависимостями вызвана зависимостями! Я предлагаю вам выполнить следующие шаги:

  1. Загрузите Dependency Walker с http://www.dependencywalker.com/

  2. Запустите Dependency Walker и откройте dll (в моем случае NativeInterfaces.dll)

  3. Вы можете увидеть один или несколько DLL с ошибкой в красном Ошибка открытия файла...

  4. Это означает, что эта DLL отсутствует в вашей системе; в моем случае имя dll MSVCR71.DLL

  5. Вы можете скачать отсутствующие dll из Google и скопировать по правильному пути (в моем случае c:\windows\system32)

  6. На этом этапе вы должны зарегистрировать новый dll в GAC (Global Assembly Cache): откройте терминал DOS и напишите:

    cd \Windows\System32
    regsvr32 /i msvcr71.dll
    
  7. Перезапустите ваше приложение!

Ответ 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

screenshot В проводнике решений щелкните правой кнопкой мыши по проекту (а не по решению), на вкладке сборки выберите Платформа цели: "Любой процессор".

Ответ 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

У меня была та же проблема, я решил ее с помощью инструкций ниже:

  1. откройте меню инструментов и выберите опцию
  2. в настройках окна перейдите в раздел Проекты и решения/Веб-проекты
  3. проверьте use the 64bit version of IIS...

enter image description here

Ответ 30

если вы получаете это сообщение об ошибке, открыв приложение на вашем Windows XP, это означает, что сначала вы установили это приложение из-за того, что он не работает без сети 4 и пакета обновления 3. вы установили оба, и снова вы получаете эту ошибку, поэтому вам нужно снова установить это приложение, но сначала удалить из add и remove

Если это не работает, пожалуйста, не злоупотребляйте мной. я также младший