Маніфестне визначення розташованої збірки не відповідає посиланням на збірку

Я намагаюся запустити кілька тестових одиниць у програмі C # Windows Forms (Visual Studio 2005), і я отримую таку помилку:

System.IO.FileLoadException: Не вдалося завантажити файл або збірку 'Utility, Версія = 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: Не вдалося завантажити файл або збірку 'Utility, Version = 1.2.0.203, Culture = нейтральна, PublicKeyToken = 764d581291d764f7' або одна з її залежностей. Маніфестне визначення розташованої збірки не відповідає посиланням на збірку. (Виняток з HRESULT: 0x80131040)

Я переглядаю свої посилання, і я маю лише посилання на Utility version 1.2.0.203(інша - стара).

Будь-які пропозиції щодо того, як я з'ясував, на що намагається посилатися на цю стару версію цього файлу DLL?

Крім того, я не думаю, що у мене навіть на жорсткому диску ця стара збірка. Чи є інструмент для пошуку цієї старої версії?

Навантажувач .NET Assembly:

• не вдається знайти 1.2.0.203
• але знайшов 1.2.0.200

Ця збірка не відповідає тому, що було запропоновано, і тому ви отримуєте цю помилку.

Простими словами, він не може знайти збірку, на яку посилався. Переконайтеся, що він може знайти правильну збірку, помістивши її в GAC або в шлях застосування. Також дивіться https://docs.microsoft.com/archive/blogs/junfeng/the-location-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference .

Ви можете виконати пару речей, щоб вирішити цю проблему. По-перше, використовуйте пошук файлів Windows для пошуку на вашому жорсткому диску (.dll). Після того, як у вас з'явиться список результатів, зробіть Перегляд-> Виберіть деталі ..., а потім встановіть прапорець "Версія файлу". Це відобразить номер версії у списку результатів, тож ви зможете побачити, звідки може надходити стара версія.

Крім того, як сказав Ларс, перевірте свій GAC, щоб побачити, яка версія там перелічена. У цій статті Microsoft зазначається, що збірки, знайдені в GAC, не копіюються локально під час збирання, тому вам може знадобитися видалити стару версію, перш ніж проводити перезавантаження всіх. (Дивіться мою відповідь на це запитання щодо приміток щодо створення пакетного файлу, щоб зробити це для вас)

Якщо ви все ще не можете зрозуміти, звідки походить стара версія, ви можете скористатися додатком fuslogvw.exe, який постачається разом із Visual Studio, щоб отримати більше інформації про помилки прив’язки. Microsoft має інформацію про цей інструмент тут . Зауважте, що вам потрібно буде включити ведення журналу, встановивши HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLogключ реєстру на 1.

Я просто зіткнувся з цією проблемою, і я виявив, що це питання дещо інше, ніж те, з чим стикалися інші.

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

Не вдалося завантажити файл або збірку 'CompanyClasses, версія = 1.4.1.0, культура = нейтральна, 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), і ця помилка пішла для мене.

Наступна перенаправляє будь-яку версію збірки до версії 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) це не буде працювати.

Якщо ви використовуєте Visual Studio, спробуйте "чисте рішення", а потім відновіть проект.

Інші відповіді не допоможуть мені. Якщо ви не переймаєтесь версією, і ви просто хочете, щоб ваш додаток запускався, клацніть правою кнопкою миші посилання та встановіть для 'конкретної версії' значення false. Це працювало для мене.

Я щойно зіткнувся з цією проблемою, і проблема полягала в тому, що у мене була стара копія .dll у моєму каталозі налагодження програм. Ви можете також перевірити там (замість GAC), щоб побачити, чи бачите ви його.

Я зараз всім думлю. . .

Видаліть усі <assemblyBinding> посилання з файлу .config, а потім запустіть цю команду з консолі NuGet Package Manager:

Get-Project -All | Add-BindingRedirect

Я додав пакет 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>

У моєму випадку ця помилка сталася під час роботи програми ASP.NET. Рішення полягало в тому, щоб:

1. Видаліть папки objта binпапки в проекті

Очищення не працювало, перебудова не працювала, всі посилання були чудовими, але це не було написання однієї з бібліотек. Після видалення цих каталогів все працювало чудово.

У моєму випадку це була стара версія DLL в C: \ WINDOWS \ Microsoft.NET \ Framework \ ~ \ Тимчасові файли ASP.NET \. Ви можете видалити або замінити стару версію, або ви можете видалити та додати назад посилання на DLL у своєму проекті. В основному будь-який спосіб створить новий покажчик на тимчасові файли ASP.NET.

Для нас проблему викликало щось інше. Файл ліцензії для компонентів DevExpress включав два рядки, один для старої версії компонентів, яка не була встановлена ​​на цьому конкретному комп'ютері. Видалення старішої версії з файлу ліцензії вирішило проблему.

Прикрою частиною є те, що повідомлення про помилку не вказувало на те, яке посилання викликає проблеми.

Ця точно така ж помилка викидається, якщо ви намагаєтеся запізніти прив’язку за допомогою відображення, якщо збірка, до якої ви зобов’язуєтесь, отримує сильне ім'я або змінив її маркер відкритого ключа. Помилка однакова, хоча насправді не знайдено жодної збірки із зазначеним маркером відкритого ключа.

Для усунення помилки потрібно додати правильний маркер відкритого ключа (ви можете отримати його за допомогою sn -T на dll). Сподіваюсь, це допомагає.

Міна була дуже схожою на посаду Натана Бедфорда, але з невеликим поворотом. Мій проект теж посилався на змінений DLL двома способами. 1) Безпосередньо та 2) Побічно шляхом посилання на компонент (бібліотеку класів), який сам посилався на змінений DLL. Тепер мій проект Visual studio для компонента (2) посилається на правильну версію зміненого DLL. Однак номер версії самого компенсатора НЕ змінювався. В результаті встановлення нової версії проекту не вдалося замінити цей компонент на клієнтській машині.

Кінцевий результат: Пряма посилання (1) та Непряма посилання (2) вказували на різні версії зміненого dll на клієнтській машині. На моїй машині розробки це працювало чудово.

Дозвіл: Видалити додаток; Видалити всі DLLS з папки додатків; Повторно встановіть. Простий як у моєму випадку.

Я дозволю комусь скористатися моєю глузливою стрижні. У мене є деякі залежності від абсолютно окремої програми (назвемо це App1). DLL з цього App1 втягується в мою нову програму (App2). Кожен раз, коли я роблю оновлення в APP1, мені доведеться створювати нові DLL і копіювати їх у App2. Добре. . . Я втомився копіювати та вставляти між двома різними версіями App1, тому я просто додав префікс 'NEW_' до DLL.

Добре. . . Я здогадуюсь, що процес збирання сканує папку / bin, і коли вона відповідає щось невірно, вона змінює те саме повідомлення про помилку, як зазначено вище. Я видалив свої "new_" версії, і він створив просто денді.

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

Нічого, що я виправив помилку, тому поспіхом я видалив каталог BIN взагалі. Перебудував мій вихідний код, і він працював з цього моменту.

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

Щоб виправити це, я зробив Update-Packageі очистив розчин для повного відновлення.

Це працювало для мене і це наче ледачий спосіб, але час - гроші :-P

Я отримав цю помилку під час створення сервісу зборки Team Foundation Server. Виявилося, у мене було кілька проектів у моєму рішенні, використовуючи різні версії однієї бібліотеки, додані з NuGet. Я видалив усі старі версії з NuGet і додав нову як орієнтир для всіх.

Team Foundation Server розміщує всі файли DLL в одному каталозі, і одночасно може бути лише один файл DLL певного імені.

Мій app.config містить

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

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

Я просто знайшов ще одну причину, чому я отримав цю помилку. Я очистив свій GAC від усіх версій певної бібліотеки і створив свій проект із посиланням на конкретну версію, розгорнуту разом із виконуваним файлом. Під час запуску проекту я отримав цей виняток для пошуку нової версії бібліотеки.

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

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

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

очистити і відновити рішення, можливо, не замінить усі DLL з вихідного каталогу.

Що я запропоную, спробуйте перейменувати папку з "bin" на "oldbin" або "obj" на "oldobj"

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

incase, якщо ви використовуєте будь-які сторонні DLL ті, які вам потрібно буде скопіювати в новостворену папку "bin" або "obj" після успішної збірки.

сподіваюся, що це спрацює для вас.

Видалення старої збірки з розташування папки вручну, а потім додавання посилання на нові збірки може допомогти.

У мене така ж помилка ... У моєму випадку вона була вирішена так:

• Спочатку, коли додаток було встановлено, тоді люди тут використовували 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. З повідомлення про виняток отримайте назву бібліотеки "проблема" та "очікуваний" номер версії.

2. Знайдіть усі копії цього .dll у своєму рішенні, клацніть правою кнопкою миші на них і перевірте, яка версія .dll це.

Гаразд, тому в цьому прикладі мій .dll, безумовно, 2.0.5022.0 (тому номер версії винятку неправильний).

3. Шукайте номер версії, який відображався у повідомленні «Виняток» у всіх .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" />

Робота виконана!

У моєму випадку проблема була між кріслом та клавіатурою :-)

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.

Якщо ви коли-небудь отримуєте помилку на кшталт " Дефініт маніфесту розташованої збірки не відповідає посиланню на збірку ", і якщо ви оновили на вкладці Project> Manage NuGet Packages and Update в VS , перше, що можна зробити, - спробувати встановити іншу версію пакет після перевірки версій на сторінці галереї NuGet та запуску наступної команди з Console Package Manager:

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

Хоча відповідь не пов'язана безпосередньо з відповідним пакетом, і його задали у зворотній бік, він є загальним, все-таки актуальним і сподіваюся, що він комусь допоможе.

Жодне рішення не працювало для мене. Я спробував очистити проектне рішення, видалити бін, оновити пакет, оновити пакет і так далі ... Через дві години я завантажив за замовчуванням 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>

Після цього я очистив проект, знову створив його і він спрацював. Без попередження немає проблем.

Я отримав це повідомлення про помилку через посилання на збірку, яка мала ту саму назву, що і збірка, яку я будував.

Це компілюється, але воно замінює посилання, що посилається, на поточну збірку проектів - таким чином спричиняючи помилку.

Щоб виправити це, я змінив назву проекту та властивості складання, доступні за допомогою клацання правою кнопкою миші на проект та вибору "Властивості".