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

106

Я использую 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 других пакетов).

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

.net visual-studio-2017 .net-standard-1.5 Брайан
источник

Ответы:

93

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

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

Тай Петрис
источник
Или просто добавьте ссылку на свой web.config: stackoverflow.com/a/38603514/1145177
Doug S
7
Я вытащил «4.3.0» из NuGet, но по какой-то причине VS настаивает на том, чтобы я ссылался на «4.1.2.0», у меня сработала аналогичная работа, только с другим номером версии ...
Дэвид Роджерс
У меня была такая же проблема, как у @DavidRogers в проекте MSTest. Объединение различий между app.config и packages.config решило проблему.
Octoate
да, большое спасибо ! Это было решение для моего MSTest, который не нашел тестов [MSTest][Discovery] Failed to discover tests from assembly Reason:Could not load file or assembly 'System.Reflection, Version=4.1.1.0 etc
Дэн М.
Решение сработало для меня. Проблема началась после установки HtmlAgilityPack NUGET. И не запускался из-за неправильной информации о версии в пакетах. +1
Роберто
35

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

Кори Нельсон
источник
Какое обновление Visual Studio 17? Можете указать версию?
Ронак Агравал
11
У меня все еще проблема в 15.5.5 VS2017. Похоже, есть и другие причины.
SerG
Вопрос: использует ли ваш проект .NET 4.x ссылки на пакеты или он все еще использует packages.config? Мне интересно, почему это кажется мне исправленным, в том, что я избавился от packages.config.
Кори Нельсон
2
Стоит отметить, что Visual Studio 2017 версии 15.7 и более поздних версий поддерживает перенос проекта из формата управления packages.config в формат PackageReference. docs.microsoft.com/en-us/nuget/reference/…
tranquil tarn
@tranquiltarn по вашей ссылке: «В настоящее время миграция недоступна для проектов C ++ и ASP.NET».
JP Hellemons
34

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

Тушар
источник
4
Всякий раз, когда я сталкиваюсь с проблемой, указанной OP, я удаляю информацию System.Runtime в файле .config, и это решает ее. Я согласен с вами в том, что это потенциально действующее решение. Это обычно случается со мной, когда я добавляю пакет из nuget.
Wallace B. McClure
Работал у меня. У меня ошибка xunit System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.1.2.0после обновления моих проектов до 4.7.2
Антон Круглов
Основываясь на вашем ответе, я проверил свои пакеты nuget и обнаружил, что между моими проектами требуется «Google.protobuf» (консолидация),
спасибо
29

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

Шина Агравал
источник
9
Было бы полезно лучше объяснить, почему это сработает.
Dour High Arch
Проблема с этим методом заключается в том, что всякий раз, когда вы обновляете какой-либо пакет nuget или добавляете новый пакет nuget, он будет добавлен снова.
Vibgy
16

Я решил эту ошибку, сославшись на 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>
Noffls
источник
11
Как ни странно, я решил проблему, удалив все <dependentAssembly>узлы для System.Runtime ..
Мэтт Брюертон
1
@MattBrewerton подтвердил!
Барт Де Бок,
13

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

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

записи.

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

Марко
источник
Это сработало для меня! Обязательно попробуйте это, если все остальное у вас не работает
bOkeifus
3

Эта проблема возникает, когда вы ссылаетесь на проект .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>
блеск
источник
Проблема возникла у меня после добавления проектов в качестве стандарта .NET в. Как ни странно, несмотря на удаление проекта, проблемы продолжают существовать.
d219
3

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

Наилучшие пожелания

Месут эрдоган
источник
2

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

Я исправил свою ошибку, установив NetStandard.Library в свой проект модульного тестирования.

Нвайнштейн
источник
2

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

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

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

jgmdavies
источник
2

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

Сайлас Умберто Соуза
источник
2

В 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>
Мишель Борто
источник
Это сработало для меня. Проблема началась после добавления проекта .NET Core (затем измененного на .NET Standard). Проблема осталась даже после удаления ссылки и сброса web.config (и попытки большинства других ответов, в которых упоминался стандарт .NET).
d219
2

Похоже, проблема возникает из-за конфликта версий между 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

психобои111
источник
1

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

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

спам парень
источник
1

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

Даррен Вуд
источник
1

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

Кейван Кашани
источник
1

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

Самир Саяни
источник
0

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

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

Лиам
источник
0

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

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

user5389726598465
источник
0

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

Олег Железцов
источник
0

Если он работал раньше, то должно быть изменение App.config. У меня сработало Undo App.config.

Дамита
источник
0

Я также прошел через эту ошибку и рассказываю, как я избавился от нее.

В моем случае строка ниже существовала в 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

Версия CHange

Хеманшу Бхалла
источник
0

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

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

<PropertyGroup>
  <AzureFunctionsVersion>v3</AzureFunctionsVersion>
</PropertyGroup>
Рори МакКроссан
источник