Visual Studio 2017 - Datei oder Assembly 'System.Runtime, Version = 4.1.0.0' oder eine ihrer Abhängigkeiten konnte nicht geladen werden

Ich verwende Visual Studio 2017 und versuche, eine .Net Standard 1.5-Bibliothek zu erstellen und in einem .Net 4.6.2 nUnit-Testprojekt zu verwenden.

Ich erhalte die folgende Fehlermeldung ...

Datei oder Assembly 'System.Runtime, Version = 4.1.0.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Die angegebene Datei wurde vom System nicht gefunden.

Ich habe folgendes versucht:

1. Referenz Standardbibliothek als Projektreferenz. Fehler: gibt mir den vorherigen Fehler.
2. Erstellen Sie ein NuGet-Paket für meine Standardbibliothek und verweisen Sie darauf. Fehler: Der Typ ist System.String und erwartet System.String. Dies liegt daran, dass System.Runtime vom Projekt referenziert wurde und Definitionen für alle Standardtypen enthält.
3. Referenz NuGet pkg NetStandard.Library. Fehler: Geben Sie mir den gleichen Fehler wie # ("Der Typ ist System.String und erwartet System.String"). HINWEIS: Bevor ich dies getan habe, habe ich ALLE NuGet-Pakete aus dem Projekt gelöscht und dann nur die Pakete nUnit und NetStandard.Library hinzugefügt (die 45 andere Pakete installiert haben).

Ist das ein Fehler? Gibt es eine Problemumgehung? Jede Hilfe wird geschätzt.

Ich hatte das gleiche Problem und keine Lösungsvorschläge, die ich gefunden habe, haben funktioniert. Meine Lösung für dieses Problem war: Überprüfen Sie App.config und packages.config, um festzustellen, ob die Versionen übereinstimmen.

Ursprünglich enthielt meine 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>

Aber die packages.config enthielt:

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

Ich habe den Eintrag app.config so geändert, dass er mit packages.config für die neue Version übereinstimmt:

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

Nach der Änderung wurde das Problem behoben.

Dieses Problem tritt auf, wenn Sie auf ein .NET Standard-Projekt aus einem .NET 4.x-Projekt verweisen: Keine der Nuget-Paketreferenzen des .NET Standard-Projekts wird als Abhängigkeiten eingefügt.

Um dies zu beheben, müssen Sie sicherstellen, dass Ihre .NET 4.x csproj-Datei auf aktuelle Build-Tools verweist (mindestens 14):

<Project ToolsVersion="15.0">...

Das Folgende sollte nicht mehr benötigt werden, es wurde um VS 15.3 behoben:

In VS2017 war ein Fehler bekannt, insbesondere in NuGet 4.0.

Um den Fehler zu umgehen, müssen Sie die .csproj-Datei für Ihr .NET 4.x-Projekt öffnen und dieses Snippet hinzufügen:

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

NuGet 4.x bringt die "Paketreferenz" mit - nicht mehr packages.config - aber die alte 4.x-Pipeline wurde zum Zeitpunkt des Starts von VS2017 nicht vollständig aktualisiert. Das obige Snippet scheint das Build-System "aufzuwecken", um Paketreferenzen aus Abhängigkeiten korrekt einzuschließen.

Ich bin kürzlich auf dieses Problem gestoßen und habe viele Dinge ausprobiert, die in diesem und anderen Threads erwähnt wurden. Ich habe die "System.Runtime"Paketreferenz für by nuget package manager hinzugefügt , die Bindungsprobleme behoben app.configund sichergestellt, dass app.configund package.configdieselbe Version für die Assembly vorhanden ist. Das Problem blieb jedoch bestehen.

Schließlich entfernte ich das <dependentAssembly>Tag für die Baugruppe und das Problem verschwand. Versuchen Sie also, Folgendes in Ihrem zu entfernen 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>

Bearbeiten: Nachdem ich .NET Framework auf 4.7.2 aktualisiert habe, ist das Problem erneut aufgetreten. Ich habe den obigen Trick ausprobiert, aber er hat nicht funktioniert. Nachdem ich viele Stunden verschwendet hatte, stellte ich fest, dass das Problem aufgrund einer alten System.LinqReferenz in app.config auftritt. Entfernen oder aktualisieren Sie daher auch alle Linq-Referenzen, um dieses Problem zu beheben.

Vertrau mir, ich scherze nicht. Entfernen Sie alle System.Runtime-Abhängigkeiten aus Ihrer app.config, und es funktioniert.

Ich habe diesen Fehler behoben, indem ich auf die NetStandard.Library und die folgende app.config- Datei im NUnit-Project verwiesen habe .

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

Bearbeiten

Wenn etwas anderes als System.Runtime, System.Reflectionoder System.Runtime.InteropServicesfehlt (zB System.Linq), dann fügen Sie einfach einen neuen dependentAssemblyKnoten.

Bearbeiten 2

In neuen Visual Studio-Versionen (2017, 15.8, glaube ich) ist es möglich, dass Studio die Datei app.config erstellt. Aktivieren Sie einfach das Kontrollkästchen Bindungsweiterleitungen automatisch generieren in Projekteigenschaften - Anwendung .

Bearbeiten 3

Das automatische Generieren von Bindungsumleitungen funktioniert mit .NET-Klassenbibliotheken nicht gut. Das Hinzufügen der folgenden Zeilen zu den csproj-Dateien löst dieses Problem und eine funktionierende .config-Datei für die Classlibary wird generiert.

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

Ich habe es behoben, indem ich meine app.configmit gelöscht habe

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

Einträge.

app.config wurde beim Refactoring automatisch hinzugefügt (aber nicht benötigt)

Dieses Problem tritt auf, wenn Sie auf ein .NET Standard-Projekt aus einem .NET 4.x-Projekt verweisen: Keine der Nuget-Paketreferenzen des .NET Standard-Projekts wird als Abhängigkeiten eingefügt.

Ich habe durch Hinzufügen von System.Runtime gelöst 4.3 und NETStandard.Library-Paket und !! wichtig !! Ich benutze das Refactor-Tool, um die System.Runtime.dll-Version nachzuschlagen. Dies ist 4.1.1.1nicht der Fall 4.3und füge dann in .config eine BindingRedirect hinzu

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

Es ist zu spät, ich weiß, aber es gibt keine erfolgreiche Antwort. Ich habe die Antwort von einer anderen Website gefunden. Ich habe das Problem behoben, als ich die System.Runtime-Assemblyabhängigkeit löschte. Ich habe das gelöscht.

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

Freundliche Grüße

Ich hatte ein Problem damit in einem NUnit 2.6.4-Projekt, das auf das Dotnet-Framework 4.6.2 abzielt. Beim System.Runtime FileNotFoundVersuch, Humanizer zu verwenden, ist dieser Fehler aufgetreten .

Ich habe meinen Fehler behoben, indem ich NetStandard.Library in meinem Unit-Test-Projekt installiert habe .

Wir haben festgestellt, dass AutoGenerateBindingRedirectsdies dieses Problem verursachen könnte.

Beobachtet: das gleiche Projekt Targeting net45und netstandard1.5wurde auf einer Maschine erfolgreich gebaut und es versäumt , zu bauen auf der anderen Seite . Auf Maschinen waren verschiedene Versionen des Frameworks installiert (4.6.1 - Erfolg und 4.7.1 - Fehler). Nach dem Upgrade des Frameworks auf dem ersten Computer auf 4.7.1 schlug der Build ebenfalls fehl.

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 redirectsist ein Merkmal von .net 4.5.1. Immer wenn Nuget feststellt, dass das Projekt transitiv auf verschiedene Versionen derselben Assembly verweist, wird automatisch die Konfigurationsdatei im Ausgabeverzeichnis generiert, die alle Versionen auf die am höchsten erforderliche Version umleitet.

In unserem Fall wurden alle Versionen von System.Runtimeto neu gebunden Version=4.1.0.0. .net 4.7.1Wird mit einer 4.3.0.0Laufzeitversion geliefert. Die Redirect-Bindung wurde also einer Version zugeordnet, die in einer modernen Version des Frameworks nicht verfügbar war.

Das Problem wurde behoben, indem die automatische Bindungsumleitung für das 4.5-Ziel deaktiviert und nur für den .net-Kern belassen wurde.

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

Dieses Problem hat viele Ursachen ... in meinem Fall bestand das Problem darin, dass in meiner web.config ein Tag die System.Runtime-Assembly hinzufügte:

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

Ein Paket fügte jedoch dieselbe Assembly hinzu wie die Abhängigkeit von einer anderen Version:

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

Durch Entfernen des Tags "Assembly hinzufügen" aus meiner web.config wurde das Problem behoben.

Das Problem scheint verursacht zu werden, wenn zwischen packages.config und app.config ein Versionskonflikt besteht. In app.config haben Sie Assembly-Bindungsumleitungen, die automatisch von "AutoGenerateBindingRedirects" generiert werden. Wenn diese Option jedes Mal aktiviert ist, wenn Sie das Nuget-Paket herunterladen, wird zusätzlich zum neuen Eintrag in packages.config diese verbindliche Umleitungsinformation zu app.config hinzugefügt. Der Zweck hierzu wird hier erläutert: Umleitung der Assemblybindung: Wie und warum?

Dort können Sie lesen, was Benutzer @Evk geschrieben hat:

Warum werden verbindliche Weiterleitungen überhaupt benötigt? Angenommen, Sie haben Anwendung A, die auf Bibliothek B verweist, sowie Bibliothek C der Version 1.1.2.5. Bibliothek B verweist wiederum auf Bibliothek C, jedoch auf Version 1.1.1.0. Jetzt haben wir einen Konflikt, weil Sie zur Laufzeit nicht verschiedene Versionen derselben Assembly laden können. Um diesen Konflikt zu lösen, verwenden Sie möglicherweise die Bindungsumleitung, normalerweise zur neuen Version

Also, SCHNELLFIX: Entfernen Sie alle Einträge in app.config.

In meinem Fall hat gerade dadurch das Programm angefangen zu funktionieren, aber es wird wahrscheinlich nur funktionieren, wenn Sie zur Laufzeit keine Versionskonflikte derselben Assembly haben.

Wenn Sie einen solchen Konflikt haben, sollten Sie diese Versionsnummern in app.config so korrigieren, dass sie mit den tatsächlich verwendeten Versionen von Assemblys übereinstimmen. Der manuelle Vorgang ist jedoch schmerzhaft. Ich empfehle daher, sie erneut automatisch zu generieren, indem Sie die Package Manager-Konsole öffnen und die Neuinstallation der Pakete durch Eingabe durchführen Update-Package -reinstall

Ich bin mehrmals mit meiner .NET 4.6.1-Website in diese Situation geraten. Ich habe das Problem jedes Mal erstellt, wenn ich einen Verweis auf ein separates .NET Core-Projekt hinzugefügt habe. Beim Erstellen hat Visual Studio mich korrekt darauf hingewiesen, dass solche Cross-Framework-Referenzen ungültig sind, und ich habe die Projektreferenz schnell gelöscht. Das Projekt wurde danach einwandfrei erstellt, aber der System.Runtime-Fehler trat beim Zugriff auf die Website auf und weigerte sich, zu verschwinden.

Das Update war jedes Mal lahm, aber effektiv: Ich habe das Projektverzeichnis gelöscht und es erneut aus der Quellcodeverwaltung heruntergeladen. Obwohl es keinen Unterschied zwischen vorher und nachher gab, konnte ich das Projekt erstellen und ohne Beschwerden auf die Seite zugreifen.

Ich bin gerade in einem Unit-Test-Projekt darauf gestoßen, nachdem ich MsTest V2 über Nuget hinzugefügt habe. Das Umbenennen von app.config (so effektiv entfernen) hat den Trick für mich getan.

Nachdem ich alle oben genannten Beiträge gelesen habe, bin ich mir immer noch nicht sicher warum, sorry!

Ich habe das Problem behoben, indem ich das Nuget-Paket entfernt System.Runtimeund dann neu installiert habe

In app.config oder web.config hinzufügen

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

Ich hatte ein Projekt mit dem gleichen Problem. Ich habe es mit der Änderung der Dotnet-Core-Version von 2.2 auf 2.0 gelöst. Wenn Ihr Problem weiterhin besteht, versuchen Sie diese Lösung

Entfernen Sie vor dem Ausführen der Komponententests einfach die Laufzeit-Tags aus der Datei app.config. Problem wird gelöst.

Ich hatte ein ähnliches Problem in VS 2017 15.45 - Ich fand es, als ich überprüfte, dass das Projekt, obwohl es kompiliert und ausgeführt wurde, eine system.IO.FileNotFoundException in Bezug auf System.Runtime aufwies, als ich versuchte, auf TPL-Datenflussobjekte zuzugreifen.

Als ich die Projekte in der Lösung überprüfte, fehlte einem von ihnen (dem obersten) das System.Runtime-Paket, das von den zugrunde liegenden Projekten verwendet wurde. Sobald ich es von Nuget installiert habe, hat alles richtig funktioniert.

Ich habe alle Lösungen hier ausprobiert, aber ohne Erfolg. Schließlich löste ich es, indem ich die neue csproj-Datei öffnete und den folgenden Abschnitt manuell hinzufügte:

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

Ich verwende ASP.Net CORE 2.1 und habe diesen Fehler erhalten, als ich eine .csproj aus einer Liste von ungefähr 40 in einem großen Repo ausgewählt habe. Als ich die csproj-Datei einzeln öffnete, wurde der Fehler behoben. Etwas mit dem Start des Programms war anders, als das csproj geöffnet wurde.

Ich löse dieses Problem, indem ich von .NET 4.7.2 => .NET 4.5.2 wechsle und dann wieder zu 472 wechsle. In einigen Fällen tritt dieser Fehler auf, weil der Paketmanager Abhängigkeiten nicht auflösen kann

Wenn es zuvor funktioniert, sollte es eine App.config-Änderung geben. Undo App.config hat bei mir funktioniert.

Ich habe auch diesen Fehler durchlaufen und erzählt, wie ich ihn losgeworden bin.

In meinem Fall war die folgende Zeile in der Datei web.config des Webapi-Projekts vorhanden, in der Datei package.config war jedoch keine Paketreferenz vorhanden.

Code in Web.config in Webapi Project

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

Code I In der Datei packages.config im Web-API-Projekt hinzugefügt Vor dem Schließen des Elements.

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

Eine andere Lösung hat in meinem Fall funktioniert:

Ein weiterer sicherer Kurzfilm, der möglicherweise funktioniert, wenn Sie ein Projekt auf ein anderes Computersystem kopiert haben, das möglicherweise nur wenige andere Paketversionen enthält. Sie können versuchen, die Assembly-Version in eine Version zu ändern, die auf der Website / im Webapi fälschlicherweise angegeben ist, wenn Sie es ausführen. Wie in diesem Fall, wie in Frage angegeben, ist die benötigte Version '4.1.0.0'. Versuchen Sie also einfach, die aktuelle Version in web.config auf die irrtümlich gezeigte Version wie unten zu ändern

Error:

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

Ich hatte diesen Fehler beim Erstellen einer Azure-Funktion (mit einem Warteschlangentrigger, sollte es einen Unterschied machen)

Das Problem in diesem Fall war, dass das AzureFunctionsVersionauf v2 anstelle von v3 gesetzt wurde. Um es über VS2019 zu aktualisieren, entladen Sie das Projekt und bearbeiten Sie die csproj-Datei. Fügen Sie innerhalb des PropertyGroupKnotens Folgendes hinzu / bearbeiten Sie Folgendes:

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