Определение манифеста обнаруженной сборки не соответствует ссылке на сборку


751

Я пытаюсь запустить некоторые модульные тесты в приложении C # Windows Forms (Visual Studio 2005) и получаю следующую ошибку:

System.IO.FileLoadException: Не удалось загрузить файл или сборку 'Утилита, Версия = 1.2.0.200, Культура = нейтральная, PublicKeyToken = 764d581291d764f7' или одна из ее зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040) **

в x.Foo.FooGO ()

в x.Foo.Foo2 (String groupName_) в Foo.cs: строка 123

в x.Foo.UnitTests.FooTests.TestFoo () в FooTests.cs: строка 98 **

System.IO.FileLoadException: не удалось загрузить файл или сборку 'Утилита, версия = 1.2.0.203, культура = нейтральная, PublicKeyToken = 764d581291d764f7' или одна из ее зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040)

Я смотрю в своих ссылках, и у меня есть только ссылка Utility version 1.2.0.203(другая старая).

Любые предложения о том, как я выясняю, что пытается сослаться на эту старую версию этого DLL-файла?

Кроме того, я не думаю, что у меня даже есть эта старая сборка на моем жестком диске. Есть ли инструмент для поиска этой старой версионной сборки?


В моем случае это произошло потому, что у меня было два проекта, загружавших одну и ту же DLL с разными версиями. (надеюсь, это кому-нибудь поможет!)
miguelmpn

Ответы:


461

Загрузчик сборки .NET:

  • не может найти 1.2.0.203
  • но нашел 1.2.0.200

Эта сборка не соответствует тому, что было запрошено, и поэтому вы получаете эту ошибку.

Проще говоря, он не может найти сборку, на которую ссылались. Убедитесь, что он может найти правильную сборку, поместив ее в GAC или в путь приложения. Также см. Https://docs.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference .


19
но когда я смотрю на ссылки проекта, он указывает на 1.2.0.203 .. кажется, ничто больше не указывает на 1.2.0.200
leora

128
Точно - он ищет 1.2.0.203, но нашел 1.2.0.200. Узнайте, где находится этот файл, и замените его верной версией.
Джон Скит

18
Я задал подобный вопрос здесь и получил рабочее решение: stackoverflow.com/questions/4187907/…
Michael La Voie

13
Проверьте версию ссылок, а затем посмотрите, совпадает ли она в
пакетах.config

4
Это сообщение смущает меня каждый раз. Кажется, это написано задом наперед. Я ожидаю, что он будет жаловаться на версию, которую вы просили загрузить, а не на найденную версию. Рад, что я не единственный, кто ошибается!
Грег Вудс

91

Вы можете сделать несколько вещей, чтобы устранить эту проблему. Во-первых, используйте поиск файлов Windows для поиска вашего жесткого диска для вашей сборки (.dll). Получив список результатов, выполните Вид-> Выбрать подробности ..., а затем установите флажок «Версия файла». Это отобразит номер версии в списке результатов, так что вы сможете увидеть, откуда может исходить старая версия.

Кроме того, как сказал Ларс, проверьте ваш GAC, чтобы увидеть, какая версия там указана. В этой статье Microsoft говорится, что сборки, найденные в GAC, не копируются локально во время сборки, поэтому вам может потребоваться удалить старую версию перед выполнением перестройки всех. (См. Мой ответ на этот вопрос для заметок о создании командного файла, чтобы сделать это для вас)

Если вы все еще не можете определить, откуда взялась старая версия, вы можете использовать приложение fuslogvw.exe, поставляемое с Visual Studio, для получения дополнительной информации об ошибках привязки. У Microsoft есть информация об этом инструменте здесь . Обратите внимание, что вам нужно включить ведение журнала, установив для параметра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLogреестра значение 1.


19
Не забывайте, что версия файла не является частью идентичности сборок. Версия сборки есть, но не обязательно должна совпадать с версией файла!
Ларс Труйенс

Если вы используете fuslogvw для сервисов, читайте blogs.msdn.com/b/junfeng/archive/2004/02/14/72912.aspx
Ник

Поиск имени файла решил мою проблему. У меня была старая версия dll в папке Temporary ASP.Net, и InstallShield использовал ее вместо актуальной версии! Чистое решение, перестроить, перезагрузить компьютер ничего не сделал. Работал хорошо локально и взрывался каждый раз, когда был развернут.
JumpingJezza

Сразу после сборки мой сайт работает нормально, но через некоторое время эта проблема возникает.
Shavais

Я отредактировал этот ответ, чтобы вместо этого сказать версию сборки.
Достойно7

60

Я просто столкнулся с этой проблемой сам, и обнаружил, что проблема была чем-то отличным от того, с чем столкнулись другие.

У меня было две библиотеки DLL, на которые ссылался мой основной проект: CompanyClasses.dll и CompanyControls.dll. Я получал ошибку во время выполнения, говоря:

Не удалось загрузить файл или сборку 'CompanyClasses, версия = 1.4.1.0, Culture = нейтральный, PublicKeyToken = 045746ba8544160c' или одна из ее зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку

Проблема была в том, что в моей системе не было файлов CompanyClasses.dll с номером версии 1.4.1. Ни в GAC, ни в папках приложений ... нигде. Я искал весь мой жесткий диск. Все файлы CompanyClasses.dll, которые у меня были, были 1.4.2.

Реальная проблема, которую я обнаружил, заключалась в том, что CompanyControls.dll ссылался на версию 1.4.1 CompanyClasses.dll. Я просто перекомпилировал CompanyControls.dll (после ссылки на CompanyClasses.dll 1.4.2), и эта ошибка исчезла для меня.


2
+1 Нечто подобное случилось со мной, когда одна из моих библиотек DLL ссылается на более старую версию Caliburn Micro.
Джейсон Мэсси

Я тоже, твой опыт зажег меня, где я должен смотреть, и я решил свою проблему.
Esen

Другой вариант - открыть CompanyControlsпроект, щелкнув правой кнопкой мыши CompanyClasses.dllссылку -> Свойства ->SpecificVersion = false
BlueRaja - Дэнни Пфлугхофт

это очень часто встречается в приложениях xamarin. У меня был проект xamarin.forms, отличный от проекта xamarin.droid. Я только что увидел твой пост и узнал его.
Батмачи

Если CompanyClasses.dll подписан, то SpecificVersion = falseодин не будет вырезать его. Вы будете нуждаться в bindingredirect.
Дениз Скидмор

53

Следующее перенаправляет любую версию сборки на версию 3.1.0.0. У нас есть скрипт, который всегда будет обновлять эту ссылку в App.config, поэтому нам больше никогда не придется заниматься этой проблемой.

С помощью отражения вы можете получить сборку publicKeyToken и сгенерировать этот блок из самого файла .dll.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
  </dependentAssembly>
</assemblyBinding>

Обратите внимание, что без атрибута пространства имен XML (xmlns) это не будет работать.


1
Это сработало для меня. Я изменил 'newVersion = 3.3.3' на 'newVersion = 3.1.0'
jward01

Лучше не идти по пути переплета, если вы можете избежать этого. Когда эта ошибка укусит вас, она будет сильно кусаться.
BanksySan

1
Моя проблема заключалась в том, что перенаправления указывали на несуществующие сборки. App.Config содержал информацию о сборке из последних установленных пакетов NuGet. Когда я позже понизил эти пакеты, это НЕ очистило это. Это была стандартная библиотека классов .NET, пораженная проектом модульного тестирования инфраструктуры 4.7.2. Проблема проекта модульного тестирования, представленная во время выполнения.
D-Sect

@ D-Sect верно. Если ваш источник управления показывает, что в файле web.config есть изменения (потому что вы играли с вашими NuGets), вы можете посылать туда эти bindingRedirects. Понижение рейтинга NuGets не приведет к очистке перенаправлений привязки
bkwdesign,

45

Если вы используете Visual Studio, попробуйте «чистое решение», а затем пересоберите свой проект.


14
Это обычно решение для меня. Зачастую удаляем binи objделаем это. По сути, то, на что я ссылался, все еще сидит там, пытаясь удовлетворить то же самое требование. Например, старая версия, на которую я ссылался напрямую, а новая версия на NuGet.
Дэвид Бец

Обнаружил эту проблему для нескольких библиотек DLL после извлечения из TFS. Это решение исправило это для меня.
Мило

3
Работал на меня. Удалил папку bin amd obj и решил проблему.
user1619480

Спасибо, у меня тоже сработало, просто удалив папку bin.
Cookies Dog

Для меня было достаточно удалить binпапку. Удивительно, но раньше я безуспешно пробовал чистое решение и перестраивал решение . Иногда немного странно.
Лев

36

Другие ответы не будут работать для меня. Если вам не важна версия, и вы просто хотите, чтобы ваше приложение запускалось, щелкните правой кнопкой мыши ссылку и установите для «конкретной версии» значение false ... Это сработало для меня. введите описание изображения здесь


8
Этот параметр действует только во время компиляции . После того, как он скомпилирован, ему потребуется точно такая же версия сборки, с которой вы его скомпилировали. См. Stackoverflow.com/questions/24022134/…
Ларс

22

Я только что столкнулся с этой проблемой, и проблема была в том, что у меня была старая копия .dll в моем каталоге отладки приложения. Вы можете также проверить там (вместо GAC), чтобы увидеть, видите ли вы это.


Мы просто мигрировали на другой сервер, у которого возникла эта проблема, потому что мы сохраняем резервные копии. Сработало после удаления резервных копий. Спасибо :)
Jtuck

22

Я собираюсь взорвать умы всех прямо сейчас. , ,

Удалите все <assemblyBinding>ссылки из файла .config, а затем выполните эту команду из консоли диспетчера пакетов NuGet:

Get-Project -All | Add-BindingRedirect

У меня тоже сработало. Спасибо
Олег Удовицкий,

ты сэкономил мое время Ab
Абду Имам

4
это работает, только если формат управления пакетами
package.config

1
Официально взорван разум
BGilman

Это хороший маленький трюк
hexagod

21

Я добавил пакет NuGet только для того, чтобы понять, что часть моего приложения в «черном ящике» ссылается на более старую версию библиотеки.

Я удалил пакет и сослался на статический файл DLL старой версии, но файл web.config никогда не обновлялся из:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

к чему он должен был вернуться при удалении пакета:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

Я видел это, где, по крайней мере, для модуля Entity Framework, когда вы используете NuGet, если вы щелкнете правой кнопкой мыши по своему решению, перейдите в Управление пакетами NuGet для решения, затем Установленные пакеты> Все, выберите этот модуль, выберите Управление, вы можете как правило, снимите его с вашего проекта. Это должно очистить такие вещи без необходимости делать это вручную - при условии, что поставщик проявил должную осмотрительность. Но хороший улов, как, по-видимому, иногда нет, если вы так его удалили.
vapcguy

20

В моем случае эта ошибка произошла при запуске приложения ASP.NET. Решением было:

  1. Удалите objи binпапки в папке проекта

Очистка не сработала, перестройка не сработала, все ссылки были в порядке, но не было написано ни одной библиотеки. После удаления этих каталогов все заработало отлично.


3
Спасибо, Леви Фуллер. Этот ответ должен быть выше; для моей ситуации это было точно! Для меня эта ошибка началась, когда я сделал резервную копию своего web.config и Visual Studio продолжала загружать этот файл конфигурации вместо реальной конфигурации, даже после того, как я удалила дубликатную копию. Это решило это. Спасибо.
БрюсХилл,

У меня тоже работает. Все еще не уверены, почему это работает, хотя :(
KangarooWest

14

В моем случае это была старая версия библиотеки DLL в каталоге C: \ WINDOWS \ Microsoft.NET \ Framework \ ~ \ Temporary ASP.NET Files \. Вы можете удалить или заменить старую версию, или вы можете удалить и добавить ссылку на DLL в вашем проекте. По сути, в любом случае будет создан новый указатель на временные файлы ASP.NET.


2
Это сработало для меня, когда я закрыл Visual Studio, остановил IIS и удалил все временные файлы ASP.NET. Обратите внимание, что файлы могут находиться в папке Framework и Framework64 на 64-битном компьютере, а также в папках .NET 2.0 и 4.0!
Брайан Б

Я использовал функцию поиска в меню «Пуск» Windows, чтобы найти все библиотеки DLL, созданные моим решением, а затем удалил всю партию, где бы они ни находились. Я мог бы сделать это без страха, потому что они должны создаваться только во время отладки в Visual Studio. Поскольку VS будет перестраивать такие недостающие библиотеки DLL, и ничто вне моего решения не должно ссылаться на них, это была «безопасная» операция для меня.
Зарепет

8

Для нас проблема была вызвана чем-то другим. Файл лицензии для компонентов DevExpress включал две строки, одна для старой версии компонентов, которые не были установлены на этом конкретном компьютере. Удаление более старой версии из файла лицензии решило проблему.

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


2
В моем случае после обновления до новой версии DevExpress файл .resx формы содержал ссылки на старую неустановленную версию библиотеки. Мне пришлось открыть .resx в представлении кода и либо исправить версию на новую или удалить недействительные записи.
Артемикс

5

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

Вам нужно добавить правильный токен открытого ключа (вы можете получить его, используя sn -T на dll), чтобы устранить ошибку. Надеюсь это поможет.


1
Пожалуйста, уточните - что такое "sn-T"? И куда мне добавить токен открытого ключа?
Мориц Оба

3
«sn.exe» - это инструмент, который поставляется с Visual Studio, это инструмент командной строки, который можно запустить из командной строки Visual Studio. Просто запустите командную строку Visual Studio (из меню «Пуск»), перейдите в папку, содержащую вашу сборку, и введите «sn -T <assembly>», где <assembly> - полное имя библиотеки DLL. Это получает сборку «Токен» информации. Если у вас есть это, когда вы выполняете позднюю привязку с отражением, введите информацию о токене в строку идентификатора сборки (т. Е. «Assembly = MyAssembly.dll, Открытый ключ Token = <token guid>)
Guy Starbuck

2
Спасибо за этот ответ. Я получал эту ошибку при ссылке на раздел конфигурации в моем App.ini. Я недавно подписал сборку, поэтому PublicKeyToken = null пришлось обновить новым (правильным) токеном.
Лиам

5

У меня была очень похожая ситуация с постом Натана Бедфорда, но с небольшим поворотом. Мой проект тоже ссылался на измененную dll двумя способами. 1) Непосредственно и 2) Косвенно путем ссылки на компонент (библиотеку классов), который сам имел ссылку на измененную DLL. Теперь мой проект Visual Studio для компонента (2) ссылался на правильную версию измененной библиотеки DLL. Однако номер версии самого компонента НЕ был изменен. И в результате установки новой версии проекта не удалось заменить этот компонент на клиентском компьютере.

Конечный результат: Прямая ссылка (1) и Косвенная ссылка (2) указывали на разные версии измененной библиотеки DLL на клиентском компьютере. На моей машинке это работало нормально.

Решение: удалить приложение; Удалить все библиотеки DLL из папки приложения; Переустановите. Просто в моем случае.


4

Я позволю кому-то извлечь выгоду из моей глупости. У меня есть некоторые зависимости от совершенно отдельного приложения (назовем это App1). DLL из этого App1 втянуты в мое новое приложение (App2). Каждый раз, когда я делаю обновления в APP1, я должен создавать новые DLL и копировать их в App2. Хорошо. , . Я устал от копирования и вставки между двумя разными версиями App1, поэтому я просто добавил префикс 'NEW_' к DLL.

Хорошо. , , Я предполагаю, что процесс сборки сканирует папку / bin, и когда он совпадает с чем-то неправильно, он выдает то же сообщение об ошибке, что и выше. Я удалил свои "новые_" версии, и это построено просто денди.


4

Моя проблема заключалась в копировании исходного кода на новую машину без перетаскивания ни одной из указанных сборок.

Ничто из того, что я сделал, не исправило ошибку, поэтому в спешке я вообще удалил каталог BIN. Восстановил мой исходный код, и с тех пор он работал.


4

Я хотел бы просто добавить, что я создавал базовый проект ASP.NET MVC 4 и добавил DotNetOpenAuth.AspNet через NuGet. Это привело к той же ошибке после того, как я сослался на несовпадающий файл DLL для Microsoft.Web.WebPages.OAuth.

Чтобы исправить это, я сделал Update-Packageи очистил решение для полной перестройки.

Это сработало для меня и лениво, но время это деньги :-P


1
Подобный ответ для меня. Update-Package -reinstallпереустанавливает все пакеты NuGet в той же версии.
Джесс

1
Это замечательно; спасибо за публикацию. Я попробовал все эти отличные предложения, но это было решением, которое помогло. Слава Богу за людей, которые все еще готовы опубликовать альтернативное решение, даже если их доступно 80
Hambone

4

Я получил эту ошибку при сборке на сервисе сборки Team Foundation Server. Оказалось, что в моем решении было несколько проектов с использованием разных версий одной и той же библиотеки, добавленной с NuGet. Я удалил все старые версии с NuGet и добавил новую как справочную для всех.

Team Foundation Server помещает все DLL-файлы в один каталог, и одновременно может быть только один DLL-файл с определенным именем.


Другой способ - нажать «Управление пакетами NuGet для решения ...» и обновить тестовый проект и тестируемый проект до одной и той же (самой новой) версии.
lixonn

4

Мой app.config содержит

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>

для npgsql. Каким-то образом на компьютере пользователя пропал мой app.exe.config. Я не уверен, что это был глупый пользователь, сбой установщика или антивирус. Замена файла решила проблему.


3

Я просто нашел другую причину, почему получить эту ошибку. Я очистил свой GAC от всех версий определенной библиотеки и построил свой проект со ссылкой на конкретную версию, развернутую вместе с исполняемым файлом. Когда я запускаю проект, я получаю это исключение в поисках более новой версии библиотеки.

Причиной была политика издателя . Когда я удалил версии библиотеки из GAC, я забыл удалить сборки политики издателя, а вместо того, чтобы использовать мою локально развернутую сборку, сборщик загрузок сборки обнаружил политику издателя в GAC, которая велела ему искать более новую версию.


3

Для меня конфигурация покрытия кода в файле "Local.testtesttings" "вызвала" проблему. Я забыл обновить файлы, на которые есть ссылки.


3

Простое удаление содержимого папки bin вашего проекта и перестроение решения решило мою проблему.


1
Ну, что ты знаешь, ты только что помог мне избавиться от моих страданий, действительно спасибо
Ронни Махлангу

2

очистить и перестроить решение может не заменить все библиотеки DLL из выходного каталога.

я предлагаю переименовать папку из «bin» в «oldbin» или из «obj» в «oldobj»

а затем попробуйте снова построить свой силуэт.

incase, если вы используете какие-либо сторонние dll-файлы, которые вам нужно будет скопировать во вновь созданную папку "bin" или "obj" после успешной сборки.

надеюсь, что это будет работать для вас.


1

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


1

Я получил ту же ошибку ... В моем случае это было решено следующим образом:

  • Сначала, когда приложение было установлено, тогда люди использовали Microsoft Enterprise Library 4.1 в приложении.
  • На предыдущей неделе мой компьютер был отформатирован, и после этого сегодня, когда я создавал это приложение, он выдал ошибку, что сборка Enterprise Library отсутствует.
  • Затем я установил Microsoft Enterprise Library 5.0, которую я получил в Google в качестве первой поисковой записи.
  • Затем, когда я построил приложение, он дал мне вышеуказанную ошибку, т.е. определение манифеста расположенной сборки не соответствует ссылке на сборку.
  • После значительной части поисковой работы и анализа я обнаружил, что приложение ссылалось на 4.1.0.0, а DLL в папке bin была версии 5.0.0.0.
  • Затем я установил Microsoft Enterprise Library 4.1.
  • Удалена предыдущая ссылка (5.0) и добавлена ​​ссылка 4.0.
  • Построил приложение и вуаля ... это работало.

1

Вот мой метод решения этой проблемы.

  1. Из сообщения об исключении получите имя «проблемной» библиотеки и «ожидаемый» номер версии.

введите описание изображения здесь

  1. Найдите все копии этого .dll в вашем решении, щелкните правой кнопкой мыши по ним и проверьте, какая версия .dll это.

введите описание изображения здесь

Итак, в этом примере мой .dll определенно равен 2.0.5022.0 (поэтому номер версии Exception неверен).

  1. Найдите номер версии, который был показан в сообщении об исключении во всех файлах .csproj в вашем решении. Замените этот номер версии на фактический номер из DLL.

Итак, в этом примере я бы заменил это ...

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

... с этим...

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

Работа выполнена !


Что делать, если мои файлы csproj не имеют ссылки на версию?
Джон Деметриу

1

В моем случае проблема была между стулом и клавиатурой :-)

Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)

Две или более разных сборок хотели использовать другую версию библиотеки DotNetOpenAuth, и это не было бы проблемой. Кроме того, на моем локальном компьютере NuGet автоматически обновляет web.config:

<dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
    <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>

Затем я понял, что забыл скопировать / развернуть новый файл web.config на рабочем сервере. Поэтому, если у вас есть способ ручного развертывания web.config, убедитесь, что он обновлен. Если у вас совершенно другой файл web.config для производственного сервера, вы должны синхронизировать этот раздел зависимых сборок после использования NuGet.


1

Если вы когда-нибудь получите ошибку вроде " Определение манифеста обнаруженной сборки не соответствует ссылке на сборку », и если вы обновились через « Проект»> «Управление пакетами NuGet и вкладка« Обновление »в VS» , первое, что вы можете сделать, это попробовать установить другую версию пакет после проверки версий со страницы галереи NuGet и запуска следующей команды из консоли диспетчера пакетов:

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

Хотя ответ не имеет прямого отношения к рассматриваемому пакету и его спросили еще в обратном направлении, он носит общий характер, все еще актуален и надеется, что он кому-то поможет.


1

Ни одно решение не сработало для меня. Я попытался очистить решение проекта, удалить bin, пакет обновления, пакет downgrade и т. Д. Через два часа я загрузил App.config по умолчанию из проекта со сборками и там я изменил неверную эталонную версию с:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

чтобы:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

После этого я очистил проект, собрал его снова, и он заработал. Нет предупреждения, нет проблем.


0

Я получил это сообщение об ошибке из-за ссылки на сборку с тем же именем, что и сборка, которую я собирал.

Это скомпилировано, но оно перезаписало ссылочную сборку текущей сборкой проектов, что вызвало ошибку.

Чтобы исправить это, я изменил название проекта и свойства сборки, доступные при щелчке правой кнопкой мыши по проекту и выборе «Свойства».

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.