Visual Studio 2017 - не удалось загрузить файл или сборку System.Runtime, Version = 4.1.0.0 или одну из его зависимостей.

Я использую Visual Studio 2017 и пытаюсь создать библиотеку .Net Standard 1.5 и использовать ее в тестовом проекте nUnit .Net 4.6.2.

Я получаю следующую ошибку ...

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

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

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

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

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

<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: ни одна из ссылок на пакет 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 приносит с собой «ссылку на пакет» - больше никаких пакетов.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. Добавление следующих строк в файлы csproj решает эту проблему, и будет создан рабочий файл .config для Classlibary.

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

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

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

записи.

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

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

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

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

Я исправил свою ошибку, установив 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>

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

Прочитав все вышеперечисленные сообщения, я все еще не понимаю, почему, извините!

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

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

Похоже, проблема возникает из-за конфликта версий между packages.config и app.config. В app.config у вас есть перенаправления привязки сборки, автоматически генерируемые функцией AutoGenerateBindingRedirects. Если этот параметр включен каждый раз, когда вы загружаете пакет nuget, он будет, помимо создания новой записи в packages.config, добавлять эту информацию о перенаправлении привязки в app.config. Какова цель этого, объясняется здесь: Перенаправление привязки сборки: как и почему?

Там вы можете прочитать, что написал пользователь @Evk:

Зачем вообще нужны привязки перенаправления? Предположим, у вас есть приложение A, которое ссылается на библиотеку B, а также на библиотеку C версии 1.1.2.5. Библиотека B, в свою очередь, также ссылается на библиотеку C, но версии 1.1.1.0. Теперь у нас конфликт, потому что вы не можете загружать разные версии одной и той же сборки во время выполнения. Чтобы разрешить этот конфликт, вы можете использовать перенаправление привязки, обычно к новой версии.

Итак, БЫСТРОЕ ИСПРАВЛЕНИЕ: удалите все записи в app.config.

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

Если у вас есть такой конфликт, вы должны исправить эти номера версий в app.config, чтобы они соответствовали фактически используемым версиям сборок, но ручной процесс болезнен, поэтому я предлагаю автоматически сгенерировать их снова, открыв Консоль диспетчера пакетов и выполнить переустановку пакетов, набрав Update-Package -reinstall

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

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

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

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

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

У меня была аналогичная проблема в VS 2017 15.45 - я обнаружил, когда проверил, что, несмотря на то, что проект скомпилирован и запустил, он обнаружил исключение system.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. У меня сработало Undo 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>

Код, который я добавил в файл packages.config в проекте веб-API Перед закрытием элемента.

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

В моем случае сработало другое решение:

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