Не вдалося завантажити файл чи збірку або одну з його залежностей

У мене є ще одна з цих проблем "Не вдалося завантажити файл чи збірку або одну з її залежностей".

Додаткова інформація: Не вдалося завантажити файл або збірку "Microsoft.Practices.Unity, Версія = 1.2.0.0, Культура = нейтральна, PublicKeyToken = 31bf3856ad364e35" або одна з її залежностей. Маніфестне визначення розташованої збірки не відповідає посиланням на збірку. (Виняток з HRESULT: 0x80131040)

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

Я здійснив пошук у своїх каталогах .csproj-файлів рішень, і я маю:

Посилання включає = "Microsoft.Practices.Unity, версія = 2.0.414.0, культура = нейтральна, PublicKeyToken = 31bf3856ad364e35, процесорArchitecture = MSIL"

В жодному моєму проекті не можу знайти жодної посилання, яка суперечить 1.2.0.0.

Будь-які ідеї, як мені слід вирішувати це?

Я також вдячний порадам, як налагодити подібні проблеми в цілому.

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

2. Може бути папка виводу, де всі проекти будують свої збірки, має стару версію єдності.

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

Відкрийте менеджер IIS

Виберіть Пул програми

потім виберіть пул, який ви використовуєте

перейти до розширених налаштувань (праворуч)

Змініть прапор Enable 32-bit application false на true.

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

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

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

На 99% не вдалося завантажити файл чи збірку або одна з проблем залежності викликана залежностями! Я пропоную вам виконати наступні кроки:

1. Завантажте Уокер-залежність від http://www.dependencywalker.com/

2. Запустіть ходунок залежності і відкрийте dll (у моєму випадку NativeInterfaces.dll)

3. Ви можете побачити один або кілька dll з помилкою в червоному Помилка відкриття файлу ...

   

4. Це означає, що цей dll відсутній у вашій системі; в моєму випадку назва dllMSVCR71.DLL

5. Ви можете завантажити miss goll з 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 правильна, але слід також врахувати:

Для єдності 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. Goto project Properties >> Build
5. Змініть конфігурацію до випуску
6. Початок налагодження (F5)

1), 2)

4), 5)

Сподіваюсь, це теж допоможе вам.

• Перейти: Рішення -> Пакет
• Клацніть на вкладку « Додатково » (Знайти нижче сторінки)
• Додайте dll до додаткових збірок (таким чином ми можемо додавати зовнішні dll у спільну точку).

Не впевнений, чи це може допомогти.

Перевірте, чи збігаються ім'я збірки та простір імен за замовчуванням у проспектах у ваших збірках. Це вирішило мою проблему, яка спричинила ту саму помилку.

У моєму випадку в папці bin був нереференційний DLL під назвою Unity.MVC3, я намагався шукати будь-яку посилання на це у візуальній студії без успіху, тому моє рішення було таким простим, як видалити цей 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 з "Будь-яким процесором", коли батьківська бібліотека очікувала компіляції "x64".

У мене була така ж проблема, я вирішив її за допомогою наведених нижче інструкцій:

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

Ви повинні видалити файл appname.dll зі своєї вихідної папки. Очищення налагодження та звільнення папок. Відновіть і скопіюйте для виведення регенерований файл DLL.

Я "Встановлюю як проект запуску" розвантажену / необгрунтовану бібліотеку / проект

Потім розгорнув його.

Це спрацювало!

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

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

Моє рішення для .NET 4.0, використовуючи Enterprise Library 5, було додати посилання на:

Microsoft.Practices.Unity.Interception.dll

Слідкуйте за суперечливими посиланнями. Навіть після очищення та відновлення конфліктні посилання все одно спричинять проблеми. Моя проблема була між AForge та Accord. Я видалив обидві посилання та повторно додав посилання, повторно вибравши конкретне посилання (зокрема, у моєму випадку, лише Accord).

Для мене відбудована гра єдності без Unity C # Proects Checkmark.

У моєму випадку жодна із запропонованих відповідей не спрацювала.

Ось що для мене спрацювало:

1. Видаліть посилання
2. Перейменуйте DLL
3. Імпортуйте посилання ще раз

Другий крок був важливим, мабуть, тому що без нього не обійшлося.

Спробуйте перевірити, чи для властивості "Копіювати в локальну" для посилання встановлено значення "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. ви встановили і те, і знову, ви отримуєте цю помилку, тому вам слід перевстановити цю програму ще раз, але спочатку видаліть додавання та видалення

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