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:
- Referenz Standardbibliothek als Projektreferenz. Fehler: gibt mir den vorherigen Fehler.
- 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.
- 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.
[MSTest][Discovery] Failed to discover tests from assembly Reason:Could not load file or assembly 'System.Reflection, Version=4.1.1.0 etc
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):
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:
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.
quelle
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 behobenapp.config
und sichergestellt, dassapp.config
undpackage.config
dieselbe 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 entfernenapp.config
.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.Linq
Referenz in app.config auftritt. Entfernen oder aktualisieren Sie daher auch alle Linq-Referenzen, um dieses Problem zu beheben.quelle
xunit System.IO.FileNotFoundException: Could not load file or assembly 'System.Runtime, Version=4.1.2.0
nach dem Upgrade meiner Projekte auf 4.7.2Vertrau mir, ich scherze nicht. Entfernen Sie alle System.Runtime-Abhängigkeiten aus Ihrer app.config, und es funktioniert.
quelle
Ich habe diesen Fehler behoben, indem ich auf die NetStandard.Library und die folgende app.config- Datei im NUnit-Project verwiesen habe .
Bearbeiten
Wenn etwas anderes als
System.Runtime
,System.Reflection
oderSystem.Runtime.InteropServices
fehlt (zBSystem.Linq
), dann fügen Sie einfach einen neuendependentAssembly
Knoten.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.
quelle
<dependentAssembly>
Knoten für System.Runtime entfernt habe.Ich habe es behoben, indem ich meine
app.config
mit gelöscht habeEinträge.
app.config
wurde beim Refactoring automatisch hinzugefügt (aber nicht benötigt)quelle
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 ist4.1.1.1
nicht der Fall4.3
und füge dann in .config eine BindingRedirect hinzuquelle
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
quelle
Ich hatte ein Problem damit in einem NUnit 2.6.4-Projekt, das auf das Dotnet-Framework 4.6.2 abzielt. Beim
System.Runtime FileNotFound
Versuch, Humanizer zu verwenden, ist dieser Fehler aufgetreten .Ich habe meinen Fehler behoben, indem ich NetStandard.Library in meinem Unit-Test-Projekt installiert habe .
quelle
Wir haben festgestellt, dass
AutoGenerateBindingRedirects
dies dieses Problem verursachen könnte.Beobachtet: das gleiche Projekt Targeting
net45
undnetstandard1.5
wurde 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.Auto binding redirects
ist 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.Runtime
to neu gebundenVersion=4.1.0.0
..net 4.7.1
Wird mit einer4.3.0.0
Laufzeitversion 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.
quelle
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:
Ein Paket fügte jedoch dieselbe Assembly hinzu wie die Abhängigkeit von einer anderen Version:
Durch Entfernen des Tags "Assembly hinzufügen" aus meiner web.config wurde das Problem behoben.
quelle
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:
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
quelle
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.
quelle
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!
quelle
Ich habe das Problem behoben, indem ich das Nuget-Paket entfernt
System.Runtime
und dann neu installiert habequelle
In app.config oder web.config hinzufügen
quelle
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
quelle
Entfernen Sie vor dem Ausführen der Komponententests einfach die Laufzeit-Tags aus der Datei app.config. Problem wird gelöst.
quelle
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.
quelle
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:
quelle
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.
quelle
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
quelle
Wenn es zuvor funktioniert, sollte es eine App.config-Änderung geben. Undo App.config hat bei mir funktioniert.
quelle
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
Code I In der Datei packages.config im Web-API-Projekt hinzugefügt Vor dem Schließen des Elements.
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:
quelle
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
AzureFunctionsVersion
auf 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 desPropertyGroup
Knotens Folgendes hinzu / bearbeiten Sie Folgendes:quelle