it-swarm.com.de

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 folgende Fehlermeldung ...

Datei oder Assembly 'System.Runtime, Version = 4.1.0.0, .__ konnte nicht geladen werden. Kultur = neutral, PublicKeyToken = b03f5f7f11d50a3a 'oder einer seiner Abhängigkeiten. Die angegebene Datei wurde vom System nicht gefunden.

Ich habe folgendes versucht:

  1. Referenz-Std-Bibliothek als Projektreferenz. Error: Gibt mir den vorherigen Fehler.
  2. Erstellen Sie ein NuGet-Paket für meine Std-Bibliothek 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 hat.
  3. Referenz NuGet pkg NetStandard.Library. Fehler: Gib den gleichen Fehler wie # ("Der Typ ist System.String, 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 (die 45 andere Pakete installiert haben) hinzugefügt.

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

68
Brian

Ich hatte das gleiche Problem, und es wurde kein Lösungsvorschlag gefunden, den ich gefunden habe. Meine Lösung für dieses Problem war: Überprüfen Sie App.config und packages.config, um zu sehen, 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 für die neue Version mit packages.config ü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.

51
Ty Petrice

Dieses Problem tritt auf, wenn Sie aus einem .NET 4.x-Projekt auf ein .NET Standard-Projekt verweisen: Keine der Nuget-Package-Referenzen des .NET Standard-Projekts werden als Abhängigkeiten übernommen.

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

<Project ToolsVersion="15.0">...

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

Es gab einen bekannten Fehler in VS2017, speziell in NuGet 4.0.

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

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

NuGet 4.x bringt die "Paketreferenz" mit - keine weitere packages.config -, aber die alte 4.x-Pipeline wurde zum Zeitpunkt des Starts von VS2017 nicht vollständig aktualisiert. Das obige Snippet scheint das Buildsystem "aufzuwecken", um Paketverweise aus Abhängigkeiten korrekt aufzunehmen.

24
Cory Nelson

Ich habe dieses Problem vor kurzem und ich habe viele Dinge ausprobiert, die in diesem Thread und anderen erwähnt werden. Ich habe die Paketreferenz für "System.Runtime" von nuget package manager hinzugefügt, die Bindungswiederholungen in app.config behoben und sichergestellt, dass app.config und package.config dieselbe Version für die Assembly haben. Das Problem blieb jedoch bestehen. 

Schließlich entfernte ich das <dependentAssembly>-Tag für die Assembly und das Problem verschwand. Versuchen Sie also, Folgendes in Ihrem app.config zu entfernen.

<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 es hat nicht funktioniert. Nachdem ich viele Stunden verschwendet hatte, wurde mir klar, dass das Problem auf einen alten System.Linq-Verweis in der app.config zurückzuführen ist. Entfernen oder aktualisieren Sie daher alle Linq-Referenzen, um dieses Problem zu beheben.

22
Tushar

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

18
Sheena Agrawal

Ich habe diesen Fehler behoben, indem ich auf die NetStandard.Library und die folgende app.config -Datei im NUnit-Projekt 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.Reflection oder System.Runtime.InteropServices fehlt (z. B. System.Linq), fügen Sie einfach einen neuen dependentAssembly-Knoten hinzu.

Edit 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 Automatische Generierung von Bindungsumleitungen in Project-Properties - Application . Auto-generate binding redirects

11
Noffls

Ich habe es behoben, indem ich meinen app.config mit löschte 

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

einträge.

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

11
Marco

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

Beobachtet: dasselbe Projekt-Targeting net45 und netstandard1.5 wurde erfolgreich auf einer Maschine erstellt und konnte auf der anderen nicht erstellt werden. Auf Rechnern waren verschiedene Versionen des Frameworks installiert (4.6.1 - Erfolg und 4.7.1 - Fehler). Nach dem Upgrade des Frameworks auf der ersten Maschine 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 redirects ist eine Funktion von .net 4.5.1. Immer wenn Nuget feststellt, dass das Projekt verschiedene Versionen derselben Assembly transitiv referenziert, generiert es automatisch die Konfigurationsdatei im Ausgabeverzeichnis und leitet alle Versionen auf die höchste erforderliche Version um.

In unserem Fall wurden alle Versionen von System.Runtime wieder zu Version=4.1.0.0 gebunden. .net 4.7.1 wird mit einer 4.3.0.0-Version der Laufzeit geliefert. Die Umleitungsbindung wurde also auf eine Version abgebildet, die in einer aktuellen Version des Frameworks nicht verfügbar war.

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

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

Ich hatte ein Problem damit in einem NUnit 2.6.4-Projekt, das auf das Dotnet-Framework abzielt. 4.6.2. Ich bin auf diesen System.Runtime FileNotFound-Fehler gestoßen, als ich versucht habe, Humanizer zu verwenden.

Ich habe meinen Fehler durch die Installation von NetStandard.Library in meinem Gerätetestprojekt behoben.

1
nweinstein

Ich bin gerade erst in einem Unit-Test-Projekt nach dem Hinzufügen von MsTest V2 über Nuget darauf gestoßen. Das Umbenennen von app.config (das so effektiv entfernt wurde) hat für mich den Trick gebracht.

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

1
jgmdavies

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

1
keivan kashani

Ich bin in dieser Situation mehrmals mit meiner .NET 4.6.1-Website gelandet. Ich habe das Problem jedes Mal erstellt, wenn ich einen Verweis auf ein separates .NET Core-Projekt hinzufügte. Beim Erstellen hat Visual Studio richtig darauf hingewiesen, dass solche Cross-Framework-Referenzen ungültig sind, und ich habe die Projektreferenz schnell gelöscht. Das Projekt wurde danach gut erstellt, der System.Runtime-Fehler trat jedoch beim Zugriff auf die Website auf und weigerte sich, wegzugehen.

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

1
spamguy

Ich verwende ASP.Net CORE 2.1, und ich erhielt diesen Fehler, als ich durch die Auswahl eines .csproj aus einer Liste von etwa 40 in einem großen Repo lief. Als ich die csproj-Datei einzeln geöffnet habe, wurde der Fehler behoben. Beim Start des Programms war etwas anders, als das Programm gestartet wurde. 

0

Wenn es zuvor funktioniert, sollte sich die App.config ändern. Undo App.config hat bei mir funktioniert.

0
Damitha

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

Ich habe alle Lösungen hier ausprobiert, aber ohne Erfolg. Schließlich löste ich es, indem ich die neue csproj-Datei öffne 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>
0

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

Wenn ich die Projekte in der Projektmappe überprüfte, fehlte bei einem von ihnen (dem obersten) das System.Runtime-Paket, das von den zugrunde liegenden Projekten verwendet wird. Nachdem ich es von Nuget installiert hatte, funktionierte alles richtig.

0
Liam

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>
0
Michele Bortot

Dieses Problem tritt auf, wenn Sie auf ein .NET Standard-Projekt aus einem .NET 4.x-Projekt verweisen: Es werden keine Nuget-Paketverweise des .NET Standard-Projekts als Abhängigkeiten eingefügt.

Ich löste durch Hinzufügen von System.Runtime 4.3 und NETStandard.Library-Paket und !! wichtig !! Ich verwende das Refactor-Tool, um die Version von System.Runtime.dll nachzuschlagen. Es ist 4.1.1.1 nicht 4.3 und füge dann ein bindingRedirect in .config 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>
0
shine

Ich habe das Problem behoben, indem ich das Nuget-Paket System.Runtime entfernt und es dann erneut installiert habe

0
Darren Wood

Dieses Problem hat viele Ursachen ... In meinem Fall bestand das Problem darin, dass in meiner web.config ein Tag zum Hinzufügen der System.Runtime-Assembly hinzugefügt wurde:

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

ein Paket hat jedoch dieselbe Assembly als Abhängigkeit zu anderen Versionen hinzugefügt:

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

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