Visual Studio 2017 - Не вдалося завантажити файл чи збірку "System.Runtime, Version = 4.1.0.0" або одна з її залежностей

Я використовую Visual Studio 2017 і намагаюся створити бібліотеку .Net Standard 1.5 і використовувати її в тестовому проекті .Net 4.6.2 nUnit.

Я отримую таку помилку ...

Не вдалося завантажити файл чи збірку "System.Runtime, Version = 4.1.0.0, Culture = нейтральна, PublicKeyToken = b03f5f7f11d50a3a" або одна з її залежностей. Система не може знайти вказаний файл.

Я спробував таке:

1. Довідкова бібліотека Std як посилання на проект. Помилка: дає мені попередню помилку.
2. Створіть NuGet pkg для моєї бібліотеки Std та посилайтеся на це. Помилка: тип - System.String, очікуючи System.String. Це відбувається тому, що System.Runtime закінчився посиланням на проект, і він має визначення для всіх стандартних типів.
3. Довідка NuGet pkg NetStandard.Library. Помилка: дайте мені ту ж помилку, що і # ("Тип - System.String, очікуючи System.String"). ПРИМІТКА. Перш ніж це зробити, я очистив усі пакети NuGet від проекту, а потім додав лише пакети nUnit та NetStandard.Library (на яких встановлено 45 інших пакетів).

Це помилка? Чи існує обхід? Будь-яка допомога вдячна.

У мене була така ж проблема, і жодне запропоноване рішення, яке я знайшов, працює. Моє рішення для цієї проблеми було: Перевірте App.config і пакети.config, щоб побачити, чи відповідають версії.

Спочатку мій app.config містив:

<dependentAssembly>
  <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

Але пакети.config містили:

<package id="System.Runtime" version="4.3.0" targetFramework="net461" requireReinstallation="true" />

Я змінив запис app.config, щоб він відповідав пакетам.config для newVersion:

<dependentAssembly>
  <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.3.0" />
</dependentAssembly>

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

Ця проблема виникає, коли ви посилаєтесь на проект .NET Standard від проекту .NET 4.x: жодна із посилань на нутритний пакет .NET Standard не приводиться як залежність.

Щоб виправити це, вам потрібно переконатися, що файл .NET 4.x csproj вказує на поточні засоби збирання (принаймні 14):

<Project ToolsVersion="15.0">...

Нижче більше не потрібно, це було встановлено навколо VS 15.3:

У VS2017 була відома помилка , зокрема в NuGet 4.0.

Щоб вирішити помилку, вам потрібно відкрити файл .csproj для вашого .NET 4.x проекту та додати цей фрагмент:

<ItemGroup>
  <PackageReference Include="Legacy2CPSWorkaround" Version="1.0.0">
    <PrivateAssets>All</PrivateAssets>
  </PackageReference>
</ItemGroup>

NuGet 4.x приносить із собою "посилання на пакет" - більше не пакети.config - але старий трубопровід 4.x не був повністю оновлений на момент запуску VS2017. Вищенаведений фрагмент, здається, "прокидає" систему збирання, щоб правильно включати посилання на пакунки від залежностей.

З цим питанням я стикаюся недавно, і я спробував багато речей, згаданих у цій темі та інших. Я додав посилання на пакунок за "System.Runtime"допомогою "nuget" менеджера пакунків, виправив рядки прив'язки app.configта переконався, що app.configіpackage.config є та сама версія для складання. Однак проблема зберігалася.

Нарешті я видалив <dependentAssembly>тег для складання, і проблема зникла. Отже, спробуйте видалити наступне у своєму app.config.

<dependentAssembly>
    <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.1.0" />
</dependentAssembly>

Редагувати: Після оновлення .NET Framework до 4.7.2 проблема знову з’явилася. Я спробував описаний вище трюк, але це не вийшло. Затративши багато годин, я зрозумів, що проблема виникає через стару System.Linqпосилання в app.config. Тому видаліть або оновіть усі посилання на Linq також для позбавлення від цієї проблеми.

Повірте, я не жартую. Видаліть усі залежності System.Runtime зі свого app.config і воно почне працювати.

Я вирішив цю помилку, посилаючись на файл NetStandard.Library та наступний файл app.config у NUnit-Project.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
        <dependentAssembly>
            <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="System.Reflection" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
        </dependentAssembly>
        <dependentAssembly>
            <assemblyIdentity name="System.Runtime.InteropServices" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
            <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.1.0" />
        </dependentAssembly>
    </assemblyBinding>
</runtime>

Редагувати

Якщо нічого іншого, окрім System.Runtime, System.Reflectionабо System.Runtime.InteropServicesвідсутнє (наприклад System.Linq), просто додайте новий dependentAssemblyвузол.

Редагуйте 2

У нових версіях Visual Studio (2017, 15.8, я думаю) можливо, що Studio створить файл app.config. Просто встановіть прапорець Автоматично генерувати переадресації прив’язки, що знаходяться у Project-Properties - Application .

Правка 3

Автоматичне генерування переадресацій прив’язки не дуже добре працює з .NET Classlibraries. Додавання наступних рядків до файлів csproj вирішує це, і робочий .config файл для Classlibary буде створений.

<PropertyGroup>
  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
  <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>

Я виправив це, видаливши свою app.configс

<assemblyIdentity name="System.Runtime" ....> 

записи.

app.config було автоматично додано (але не потрібно) під час рефакторингу

Ця проблема виникає, коли ви посилаєтесь на проект .NET Standard від проекту .NET 4.x: жодна із посилань на нутритний пакет .NET Standard не приводиться як залежність.

Я вирішив, додавши 4.3пакет System.Runtime і NETStandard.Library і !! важливо !! Я використовую інструмент рефактора для пошуку версії System.Runtime.dll, це 4.1.1.1не так, 4.3а потім додайте obvezingReedirect у .config

<dependentAssembly>
    <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="4.1.1.1" />
</dependentAssembly>

я знаю, як пізно, я не знаю. Я знайшов відповідь з іншого веб-сайту. Я виправив проблему, коли видаляю залежність від сборки System.Runtime. Я видалив це.

<dependentAssembly> <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/> <bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.1.2.0"/> </dependentAssembly>

З найкращими побажаннями

У мене виникла проблема в проекті NUnit 2.6.4, орієнтованому на dotnet Framework 4.6.2. Я зіткнувся з цією System.Runtime FileNotFoundпомилкою, намагаючись використовувати Гуманізатор .

Я усунув свою помилку, встановивши NetStandard.Library у свій тестовий проект одиниці.

Ми це виявили AutoGenerateBindingRedirects може спричинити цю проблему.

Спостережувані: той же проект націлювання net45і netstandard1.5був успішно побудований на одній машині і не вдалося побудувати на інший. На машинах були встановлені різні версії рамки (4.6.1 - успіх і 4.7.1 - збій). Після оновлення фреймворку на першій машині до 4.7.1 збірка також не вдалася.

Error Message:
 System.IO.FileNotFoundException : Could not load file or assembly 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
  ----> System.IO.FileNotFoundException : Could not load file or assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.

Auto binding redirectsє особливістю .net 4.5.1. Кожного разу, коли nuget виявляє, що проект транзитивно посилається на різні версії однієї збірки, він автоматично генерує файл конфігурації у вихідному каталозі, перенаправляючи всі версії до найвищої необхідної версії.

У нашому випадку це було перезавантаження всіх версій System.Runtimeдо Version=4.1.0.0. .net 4.7.1кораблі з 4.3.0.0версією виконання. Таким чином, прив'язка переадресації була відображенням до версії, яка не була доступна в сучасній версії фреймворку.

Проблема була виправлена ​​з відключенням автоматичного перенаправлення перенаправлень для 4,5-мети та залишенням її лише для ядра .net.

<PropertyGroup Condition="'$(TargetFramework)' == 'net45'">
  <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
</PropertyGroup>

Ця проблема має багато причин ... у моєму випадку проблема полягала в тому, що в моєму web.config був тег, додаючи збірку System.Runtime:

<assemblies>
    <add assembly="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</assemblies>

але один пакет також додав ту саму збірку, що і залежність від іншої версії:

<package id="System.Runtime" version="4.3.0" targetFramework="net47" />

видалення тегу "Додати збірку" з мого web.config вирішило проблему.

Схоже, проблема виникає, коли між пакетами.config та app.config існує конфлікт між версіями. У app.config у вас є автоматичні перенаправлення, згенеровані предметом під назвою "AutoGenerateBindingRedirects". Якщо ввімкнено кожен раз, коли ви завантажуєте пакунок нута, він додасть до нового запису пакети.config додавання цієї обов'язкової інформації про переадресацію до app.config, яка мета цього пояснюється тут: Переспрямування прив'язування прив'язки: Як і чому?

Там ви можете прочитати, що написав користувач @Evk:

Чому взагалі потрібні переадресації прив’язки? Припустимо, у вас є додаток A, що посилається на бібліотеку B, а також на бібліотеку C версії 1.1.2.5. Бібліотека B в свою чергу також посилається на бібліотеку C, але версії 1.1.1.0. Зараз у нас конфлікт, оскільки ви не можете завантажувати різні версії однієї збірки під час виконання. Для вирішення цього конфлікту ви можете використовувати переадресацію прив'язки, як правило, до нової версії

Отже, Швидке виправлення: Видаліть усі записи в app.config.

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

Якщо у вас є такий конфлікт, вам слід виправити ці номери версій у app.config, щоб вони відповідали фактично використовуваним версіям збірок, але вручну процес болісний, тому я пропоную автоматично генерувати їх заново, відкривши Console Package Manager і виконайте перевстановлення пакунків, набравши Update-Package -reinstall

Я кілька разів опинився в цій ситуації на своєму веб-сайті .NET 4.6.1. Я створював проблему щоразу, коли додавав посилання на окремий проект .NET Core. Після побудови Visual Studio правильно попередив мене про те, що такі міжгалузеві посилання є недійсними, і я швидко видалив посилання на проект. Проект закінчився добре після цього, але помилка System.Runtime з'явилася під час доступу до веб-сайту і відмовилася відходити.

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

Натрапив на це щойно зараз у проекті Unit Test після додавання MsTest V2 через Nuget. Перейменування app.config (настільки ефективно його видаляючи) зробило для мене трюк.

Прочитавши всі вищезгадані пости, я досі не впевнений, чому, вибачте!

Я вирішив проблему, видаливши Nuget Package, System.Runtimeа потім перевстановив його

Додайте додаток app.config або web.config

<dependentAssembly>
    <assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>

У мене був проект із тією ж проблемою, я вирішив його зі зміною версії ядра dotnet з 2.2 на 2.0, якщо проблема залишилася, спробуйте це рішення

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

У мене була аналогічна проблема в VS 2017 15.45 - я виявив, що перевірив, що навіть незважаючи на те, що проект складений і запущений, він створив систему.IO.FileNotFoundException щодо System.Runtime, коли я намагався отримати доступ до об'єктів TPL Dataflow.

Коли я перевіряв проекти в рішенні, в одному з них (у верхньому) відсутній пакет System.Runtime, який використовувались в основних проектах. Одного разу я встановив його з Nuget, все працювало правильно.

Я спробував усі рішення тут, але безрезультатно. Врешті-решт я вирішив це, відкривши новий файл csproj і вручну додав наступний розділ:

<Reference Include="System.Runtime, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<HintPath>..\packages\System.Runtime.4.3.0\lib\net462\System.Runtime.dll</HintPath>
</Reference>

Я використовую ASP.Net CORE 2.1, і я отримав цю помилку, коли побіг, вибравши .csproj зі списку близько 40 у великому репо. Коли я відкривав файл csproj окремо, помилка була усунена. Щось із тим, як запускалася програма, було інакше, коли csproj був відкритий.

Я вирішую цю проблему, перейшовши з .NET 4.7.2 => .NET 4.5.2, а потім перейдіть до 472. Тому в деяких випадках ця помилка виникає через те, що менеджер пакунків не може вирішити залежності

Якщо він працює раніше, то слід змінити App.config. Скасувати App.config працював на мене.

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

У моєму випадку нижче рядок існував у web.config проекту webapi, але в файлі package.config не було посилання на пакет.

Код у Web.config у проекті Webapi

<dependentAssembly>
    <assemblyIdentity name="System.Runtime" publicKeyToken="B03F5F7F11D50A3A" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.3.0" />
</dependentAssembly>

Код I Доданий у пакунок.config файл у проекті веб-api Перед закриттям елемента.

<package id="System.Runtime" version="4.3.0" targetFramework="net461" />

Ще одне рішення, що працювало в моєму випадку:

Ще один звичайний короткий варіант, який може спрацювати, якщо ви скопіювали проект в іншу комп'ютерну систему, яка може мати трохи різні версії пакету, що ви можете спробувати змінити версію збірки на версію, подану помилково на веб-сайті / webapi при її запуску. Як і в цьому випадку, як зазначено у питанні, потрібна версія 4.1.0.0, тому просто спробуйте змінити поточну версію в web.config на версію, показану помилково, як показано нижче

Помилка:

Could not load file or assembly 'System.Runtime, Version=4.1.0.0' or one of its dependencies

У мене виникла помилка під час створення функції Azure (з тригером черги, чи варто це змінити)

Проблема в цьому випадку полягала в тому, що AzureFunctionsVersionвстановлено значення v2 замість v3. Щоб оновити його через VS2019, вивантажте проект і відредагуйте файл csproj. Всередині PropertyGroupвузла додайте / відредагуйте наступне:

<PropertyGroup>
  <AzureFunctionsVersion>v3</AzureFunctionsVersion>
</PropertyGroup>