Подтвердить что ты не робот

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, Культура = нейтральная, PublicKeyToken = b03f5f7f11d50a3a 'или одна из ее зависимостей. Система не может найти указанный файл.

Я пробовал следующее:

  • Справочная библиотека Std как ссылка на проект. Ошибка: дает мне предыдущую ошибку.
  • Создайте пакет NuGet для моей библиотеки Std и укажите это. Ошибка: тип - System.String, ожидающий System.String. Это связано с тем, что System.Runtime получил ссылку на проект и имеет определения для всех стандартных типов.
  • Ссылка NuGet pkg NetStandard.Library. Ошибка: введите ту же ошибку, что и # ( "Тип - System.String, ожидающий System.String" ). ПРИМЕЧАНИЕ. Прежде чем я это сделал, я удалил все пакеты NuGet из проекта, а затем добавил только пакеты nUnit и NetStandard.Library(в которых установлено еще 45 других пакетов).

Это ошибка? Есть ли работа? Любая помощь приветствуется.

4b9b3361

ОТВЕТЫ

Ответ 1

У меня была та же самая проблема, и никакие предложенные решения, которые я нашел, не работали. Мое решение для этой проблемы было: Проверьте App.config и packages.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>

Но в этом файле packages.config:

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

Я изменил запись app.config, чтобы она соответствовала packages.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>

После изменения проблема была решена.

Ответ 2

Эта проблема возникает, когда вы ссылаетесь на проект .NET Standard из проекта .NET 4.x: ни одна из ссылок пакета Nuget проекта .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 содержит "ссылку на пакет" - больше нет ни одного package.config, но старый конвейер 4.x не был полностью обновлен во время запуска VS2017. Вышеприведенный фрагмент похоже "пробуждает" систему сборки, чтобы правильно включать ссылки на пакеты из зависимостей.

Ответ 3

Я недавно столкнулся с этой проблемой, и я попробовал много вещей, упомянутых в этой теме и других. Я добавил ссылку на пакет для "System.Runtime" помощью диспетчера пакетов nuget, исправил изменения привязки в app.config и убедился, что app.config и package.config имеют одинаковую версию для сборки. Однако проблема сохраняется.

Наконец, я удалил <dependentAssembly> depenAssembly <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, чтобы избавиться от этой проблемы.

Ответ 4

Поверь мне, я не шучу. Удалите все зависимости System.Runtime из вашего app.config, и он начнет работать.

Ответ 5

Я исправил эту ошибку, сославшись на файл 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 год) возможно, что Studio создаст файл app.config. Просто установите флажок Автоматически создавать перенаправления привязки в Project-Properties - Application. Auto-generate binding redirects

Редактировать 3

Автоматически создавать перенаправления привязки не работает с библиотеками классов .NET. Решив это, добавьте следующие строки в файлы csproj, и будет создан рабочий файл .config для Classlibary.

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

Ответ 6

Я исправил это, удалив мой app.config с

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

записей.

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

Ответ 7

Мы обнаружили, что 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>

Ответ 8

Эта проблема возникает, когда вы ссылаетесь на проект .NET Standard из проекта .NET 4.x: ни одна из ссылок пакета Nuget проекта .NET Standard не вводится как зависимости.

Я решил добавить System.Runtime 4.3 и пакет NETStandard.Library и !! важно !! Я использую инструмент рефакторинга для поиска версии System.Runtime.dll, это 4.1.1.1 не 4.3 и затем добавляю bindingRedirect в .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>

Ответ 9

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

С уважением

Ответ 10

У меня возникла проблема с этим в проекте NUnit 2.6.4, ориентированном на dotnet framework 4.6.2. Я столкнулся с этой ошибкой System.Runtime FileNotFound, пытающейся использовать Humanizer.

Я исправил свою ошибку, установив NetStandard.Library в проект unit test.

Ответ 11

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

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

Ответ 12

Впервые столкнулся с этим в проекте Unit Test после добавления MsTest V2 через Nuget. Переименование app.config (так эффективно удалив его) помогло мне.

Прочитав все вышеупомянутые посты, я до сих пор не уверен, почему, извините!

Ответ 13

Эта проблема имеет много причин... в моем случае проблема заключалась в том, что в моем файле 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 решило проблему.

Ответ 14

Я исправил проблему, удалив пакет Nuget System.Runtime а затем переустановил его.

Ответ 15

У меня был проект с той же проблемой, я решил с изменением версии ядра dotnet с 2.2 на 2.0, Если ваша проблема осталась, попробуйте это решение

Ответ 16

У меня была аналогичная проблема в VS 2017 15.45 - я обнаружил, когда я проверил, что даже несмотря на то, что проект был скомпилирован и запущен, при использовании метода system.IO.FileNotFoundException в отношении System.Runtime, когда я пытался получить доступ к объектам потока данных TPL.

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

Ответ 17

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

Ответ 18

Я использую ASP.Net CORE 2.1, и я получил эту ошибку, когда бежал, выбрав .csproj из списка около 40 в большом репо. Когда я открыл файл csproj по отдельности, ошибка была устранена. Что-то с тем, как была запущена программа, отличалось при открытии csproj.

Ответ 19

Я решаю эту проблему, переключаясь с .NET 4.7.2 =>.NET 4.5.2 и затем переключаясь обратно на 472. Так что в некоторых случаях эта ошибка возникает из-за того, что менеджер пакетов не может разрешить зависимости

Ответ 20

В 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>

Ответ 21

Если это работало ранее, тогда должно быть изменение App.config. Отменить App.config работал для меня.