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

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

Дополнительная информация: Не удалось загрузить файл или сборку «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. Проверьте, ссылаетесь ли вы на сборку, которая, в свою очередь, ссылается на старую версию Unity. Например, допустим, у вас есть сборка, ServiceLocator.dllкоторая называется старой версией сборки Unity, теперь, когда вы ссылаетесь на ServiceLocatorнее, вы должны предоставить ей старую версию Unity, и это создает проблему.

2. Может быть выходная папка, где все проекты строят свои сборки, имеет старую версию unity.

Вы можете использовать FusLogVw, чтобы выяснить, кто загружает старые сборки, просто определить путь для журнала и запустить свое решение, а затем проверить (в FusLogvw) первую строку, где загружена сборка Unity, дважды щелкнуть по ней и увидеть вызывающий сборка, и здесь вы идете.

Открыть IIS Manager

Выберите пулы приложений

затем выберите пул, который вы используете

перейти к расширенным настройкам (справа)

Измените флаг Включить 32-битное приложение false на true.

Для меня ни одно из других решений не сработало (включая стратегию очистки / восстановления). Я нашел другое решение, которое заключается в закрытии и повторном открытии Visual Studio .

Я предполагаю, что это заставляет Visual Studio перезагружать решение и все проекты, перепроверяя зависимости в процессе.

Попробуйте очистить папки Debug и Release в вашем решении. Затем удалите и добавьте единство снова.

При 99% не удалось загрузить файл или сборку, или одна из проблем с зависимостями вызвана зависимостями! Я предлагаю вам выполнить следующие шаги:

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

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

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

   

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

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

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

   cd \Windows\System32
   regsvr32 /i msvcr71.dll

7. Перезапустите ваше приложение!

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 до последней версии.

Следующее сработало для меня.

• Удалите временные файлы C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Временные файлы ASP.NET
• Закройте VSTS и снова откройте
• Удалите и добавьте одинаковые библиотеки DLL (Примечание: вы добавляете одинаковые совпадающие версии)

Проверьте файл Web.config / App.config в вашем проекте. Проверьте, правильны ли номера версий.

<bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />

Это сработало для меня.

Несмотря на то, что первоначальный вопрос был опубликован пять лет назад, проблема все еще сохраняется и довольно раздражает.

Общее решение - тщательный анализ всех сборок, на которые ссылаются, чтобы понять, что происходит не так. Чтобы упростить эту задачу, я создал инструмент (расширение Visual Studio), который позволяет выбирать сборку .NET ( .dllили.exe файл файл), чтобы получить график всех сборок, на которые имеются ссылки, при выделении конфликтующих или отсутствующих ссылок.

Инструмент доступен в галерее Visual Studio: https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734

Пример вывода:

В обозревателе решений щелкните правой кнопкой мыши проект (не решение), на вкладке «Сборка» выберите цель платформы: «Любой процессор».

Ответ Juntos правильный, но вы также должны учесть:

Для Unity v2.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?

Я также получил эту ужасную ошибку и нашел решение для этого ...

1. Щелкните правой кнопкой мыши по названию решения.
2. Нажмите Чистое решение
3. Перезапустите Visual Studio
4. Перейти к проекту Свойства >> Построить
5. Изменить конфигурацию на выпуск
6. Начать отладку (F5)

1), 2)

4), 5)

Надеюсь, это поможет вам тоже.

• Перейти: Решение -> Пакет
• Нажмите на вкладку « Дополнительно» (найдите под страницей)
• Добавьте вашу dll к дополнительным сборкам (таким образом мы можем добавить внешние dll в sharepoint).

Не уверен, что это может помочь.

Убедитесь, что имя сборки и пространство имен по умолчанию в свойствах в ваших сборках совпадают. Это решило мою проблему, которая привела к той же ошибке.

В моем случае в папке bin была не ссылочная dll под названием Unity.MVC3, я безуспешно пытался найти любую ссылку на нее в visual studio, поэтому мое решение было так просто, как удалить эту dll из папки bin.

Спасибо Риддхи М. Следующее сработало для меня.

Удалите временные файлы C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Временные файлы ASP.NET Закройте VSTS и снова откройте Удалите и добавьте те же библиотеки DLL (Примечание: вы добавляете одинаковые совпадающие версии)

Вы говорите, что в вашем решении много проектов ... ну, начните с одного в верхней части порядка сборки. Получите это, чтобы построить, и как только вы выясните это, вы можете применить то же самое исправление к остальным.

Честно говоря, вам, вероятно, просто необходимо обновить вашу ссылку. Похоже, вы либо обновили свою версию и не обновили ссылки, либо это проблема относительного пути, если вы держите свое решение в системе контроля версий. Просто подтвердите свои предположения и повторно добавьте ссылку.

Следующее сработало для меня.

• Удалите временные файлы C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Временные файлы ASP.NET
  • затем щелкните правой кнопкой мыши Временные файлы Asp.net> свойства> безопасность и предоставьте полный доступ к IIS и всем пользователям, выполняющим мой проект.

Эта проблема произошла со мной, когда одна из моих зависимых библиотек компилировала DLL с «Any CPU», когда родительская библиотека ожидала компиляции «x64».

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

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

Вы должны удалить файл appname.dll из выходной папки. Очистка папок Debug и Release. Перестройте и скопируйте в выходную папку восстановленный файл DLL.

Я "Сделать стартовым проектом" выгруженную / найденную библиотеку / проект.

Затем развернул его.

Это сработало!

Я думаю, что он не смог найти .dll, потому что он не был в сборке вначале.

Другая возможная причина: убедитесь, что вы случайно не дали обоим проектам одно и то же имя сборки в свойствах проекта.

Моим решением для .NET 4.0 с использованием Enterprise Library 5 было добавить ссылку на:

Microsoft.Practices.Unity.Interception.dll

Ищите противоречивые ссылки. Даже после очистки и перестройки конфликтующие ссылки все равно будут вызывать проблемы. Моя проблема была между AForge и Accord. Я удалил обе ссылки и заново добавил ссылки, перевыбрав конкретную ссылку (в моем случае, только Accord).

Для меня восстановление игры Unity без Unity C # Proects Checkmark сработало.

В моем случае ни один из предложенных ответов не сработал.

Вот что сработало для меня:

1. Удалить ссылку
2. Переименовать DLL
3. Импортируйте ссылку снова

Второй шаг был важен, по-видимому, так как он не работал без него.

Попробуйте проверить, установлено ли для свойства «Copy to Local» для ссылки значение true, а для конкретной версии установлено значение true. Это актуально для приложений в Visual Studio.

У меня было это сегодня, и в моем случае проблема была очень странной:

  <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. Вы установили оба, и снова вы получаете эту ошибку, поэтому вы должны переустановить это приложение снова, но сначала удалить из добавить и удалить

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