Assets-Datei project.assets.json nicht gefunden. Führen Sie eine NuGet-Paketwiederherstellung aus

Ich versuche, nopCommerce (das in .NET Core geschrieben ist) zu verwenden, aber wenn ich das Projekt ausführen möchte, treten 52 Fehler auf, die mir mitteilen, dass eine Nuget-Paketwiederherstellung ausgeführt werden soll

Assets-Datei ~ \ obj \ project. Assets.json ' nicht gefunden. Führen Sie eine NuGet-Paketwiederherstellung aus, um diese Datei zu generieren. Nop.Web.MVC.Testsote

Wenn ich mit der rechten Maustaste auf die Lösung klicke und Nuget-Pakete wiederherstellen auswähle, wird folgende Meldung angezeigt:

Alle Pakete sind bereits installiert und es gibt nichts wiederherzustellen.

Diese 52 Fehler sind jedoch immer noch vorhanden. In Tools -> NuGet Package Manager -> NuGet Packages for Solution verwalten ist nichts auf der Lösung installiert. Außerdem habe ich kürzlich meinen VS2017 auf 15.5.4 aktualisiert

Um diesen Fehler unter Extras> NuGet Package Manager> Package Manager-Konsole zu beheben, führen Sie einfach Folgendes aus:

dotnet restore

Der Fehler tritt auf, weil die dotnet cli anfänglich nicht alle erforderlichen Dateien erstellt. Durch die Dotnet-Wiederherstellung werden die erforderlichen Dateien hinzugefügt.

In meinem Fall war der Fehler das GIT-Repository. Der Name enthielt Leerzeichen, sodass mein Projekt nicht wiederhergestellt werden konnte

Wenn dies Ihr Problem ist, benennen Sie das GIT-Repository beim Klonen einfach um

git clone http://Your%20Project%20With%20Spaces newprojectname

Falls die Dotnet-Wiederherstellung nicht funktioniert, können die folgenden Schritte hilfreich sein:

1. Visual Studio >> Tools >> Optionen >> Nuget Manager >> Paketquellen
2. Deaktivierte alle Paketquellen von Drittanbietern.
3. Lösung neu erstellen.

Das Schließen und erneute Öffnen von Visual Studio löste dieses Problem für mich, nachdem ich sichergestellt hatte, dass die NuGet-Pakete gemäß den anderen hier veröffentlichten Antworten wiederhergestellt wurden.

Für diejenigen mit demselben Problem wie ich in der Azure DevOps / VSTS-Umgebung, die auf eine ähnliche Meldung stoßen: C:\Program Files\dotnet\sdk\2.2.104\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(208,5): Error NETSDK1004: Assets file '...\obj\project.assets.json' not found. Run a NuGet package restore to generate this file

Fügen Sie /t:RestoreIhre MSBuild-Argumente in Build Solution hinzu.

Als ich das tat, trat immer noch ein Fehler bei der Dotnet-Wiederherstellung auf.

ich ging zu

1 Tool -> NuGet Package Maneger -> Package Manager-Einstellungen -> Klicken Sie auf "Nuget Catche (s) löschen".

2 Dotnet-Wiederherstellung

Gelöste Probleme.

Führen Sie im Visual Studio 2017 die folgenden Schritte aus:

1) Wählen Sie Tool => Options => NuGet Package Manager => Package Sources und deaktivieren Sie die Option Microsoft Visual Studio Offline Packages .

2) Öffnen Sie nun Tool => NuGet Package Maneger => Package Manager Console. 3) Befehl in PM> dotnet restore ausführen.

Hoffe es funktioniert ...

Für mich habe ich NuGet.exe von 3.4 auf 4.9 aktualisiert, da 3.4 nicht versteht, wie Pakete für .NET Core wiederhergestellt werden.

Weitere Informationen finden Sie unter Dotnet-Wiederherstellung vs. Nuget-Wiederherstellung mit Teamcity

Wählen Sie Extras > NuGet Package Manager > Package Manager-Konsole

Und dann laufen:

dotnet restore <project or solution name>

etwas spät zur Antwort, aber dies scheint einen Mehrwert zu bieten. Betrachtet man den Fehler, scheint er in der CI / CD-Pipeline aufzutreten.

Es reicht aus, nur "dotnet build" auszuführen.

Dotnet Build

dotnet build führt standardmäßig die "Wiederherstellung" aus.

Nichts oben hat bei mir funktioniert. Aber einfach alle Ordner 'bin' und 'obj' zu löschen, hat den Trick getan.

Gelöst durch Hinzufügen von / t: Restore; Build to MSBuild Arguments

Überprüfen Sie bei Verwendung von VSTS Ihre Datei global.json. Ich hatte die SDK-Version nur als "2.2" eingegeben, was einen Analysefehler verursachte (aber nicht beim lokalen Erstellen). Durch Hinzufügen der Vollversion "2.2.104" wurde das Problem behoben.

Bei diesem Fehler in Azure DevOps habe ich mehrere Stunden verloren, als ich die Aufgabe "Visual Studio Build" in einer Build-Pipeline festgelegt habe, um ein einzelnes Projekt in meiner Lösung und nicht die gesamte Lösung zu erstellen.

Dies bedeutet, dass DevOps entweder keine (oder möglicherweise einige, ich bin mir nicht sicher, welche) Projekte erstellt, auf die von dem Projekt verwiesen wird, auf das Sie für die Erstellung abzielen, und daher haben diese Projekte nicht die Datei project.json .asset-Dateien generiert, die dann dieses Problem verursachen.

Die Lösung für mich bestand darin, von der Verwendung der VS Build-Aufgabe zur MSBuild-Aufgabe zu wechseln. Wenn Sie die MSBuild-Aufgabe für ein einzelnes Projekt verwenden, werden alle Projekte, auf die von dem von Ihnen erstellten Projekt verwiesen wird, korrekt erstellt und dieser Fehler behoben.

Wenn das einfache Wiederherstellen von NuGet-Paketen nicht funktioniert, stellen Sie sicher, dass unter Extras -> Optionen -> NuGet-Paket-Manager -> Allgemein unter Paketwiederherstellung dass "NuGet das Herunterladen fehlender Pakete zulassen" aktiviert ist.

Stellen Sie dann NuGet-Pakete erneut wieder her oder erstellen Sie sie neu, nachdem Sie die Ordner obj und bin gelöscht haben.

Wenn der Vorschlag von @ mostafa-bouzari nicht hilft, überprüfen Sie sorgfältig in den Fenstern " Fehlerliste " oder "Ausgabe", ob NuGet nicht wiederhergestellt werden kann, z. B. aufgrund eines Netzproblems, wenn Sie sich hinter dem Proxy befinden.

Dieses Problem tritt auf, wenn Ihr Build-Tool nicht restoreauf Projekte eingestellt ist, die PackageReferencevs verwenden sollenpackages.config und betrifft hauptsächlich Net Core- und Netstandard-Projekte im neuen Stil.

Wenn Sie Visual Studio öffnen und erstellen, wird dies für Sie behoben. Wenn Sie jedoch Automatisierungs- und CLI-Tools verwenden, tritt dieses Problem auf.

Hier werden viele Lösungen angeboten. Aber alles, woran Sie sich erinnern müssen, müssen Sie erzwingen restore. In einigen Fällen verwenden Sie dotnet restorevor dem Erstellen. Wenn Sie mit MsBuild erstellen, fügen Sie /t:RestoreIhrem Befehl einfach einen Schalter hinzu.

Unterm Strich müssen Sie sehen, warum die Wiederherstellung nicht aktiviert werden kann. Entweder schlechte Nuget-Quelle oder fehlende Wiederherstellungsaktion oder veraltete nuget.exe oder alle oben genannten.

Sehr seltsame Erfahrung, die ich getroffen habe!

Ich hatte zuvor mit GIT bash und GIT cmd-Line geklont und bin auf die oben genannten Probleme gestoßen.

Später habe ich mit Tortoise-GIT geklont und alles hat wie erwartet funktioniert.

Vielleicht ist dies eine verrückte Antwort, aber wenn Sie es einmal versuchen, können Sie Zeit sparen!

Dies wurde gesehen, nachdem ein WinForms Core 3.1-Projekt (aus Projektvorlagen) auf VS-2019 vs 16.4.0 hinzugefügt und versucht wurde, es sofort auszuführen. Bereinigen oder neu erstellen Die gesamte Lösung hat nicht funktioniert.

Ich habe gerade meine Lösung neu geladen. Das heißt, Datei / Lösung schließen und dann wieder öffnen und neu erstellen, löste das Problem.

Wenn dieser Fehler als Teil eines Builds in Azure DevOps (TFS) auftritt und Ihr Build bereits über eine NuGet-Wiederherstellungsaufgabe verfügt , weist dieser Fehler möglicherweise darauf hin, dass die NuGet-Wiederherstellungsaufgabe nicht alle Pakete wiederherstellen konnte, insbesondere wenn Sie eine benutzerdefinierte Paketquelle verwenden ( wie ein interner NuGet-Server). Hinzufügen/t:Restore;Build zu den MSBuild-Argumenten scheint eine Möglichkeit zu sein, den Fehler zu beheben. Dies fordert MSBuild jedoch auf, einen zusätzlichen NuGet-Wiederherstellungsvorgang durchzuführen. Ich glaube, dies ist erfolgreich, da MSBuild die in Visual Studio konfigurierte benutzerdefinierte Paketquelle verwendet. Eine bevorzugte Lösung besteht darin, die NuGet-Wiederherstellungsaufgabe zu beheben.

So konfigurieren Sie eine benutzerdefinierte Paketquelle für die NuGet-Wiederherstellungsaufgabe:

1. Erstellen Sie eine NuGet.configDatei, in der alle Paketquellen aufgelistet sind (Microsoft Visual Studio Offline-Pakete, nuget.org und Ihre benutzerdefinierte Paketquelle), und fügen Sie sie der Quellcodeverwaltung hinzu.
2. Wählen Sie in der Nuget-Wiederherstellungsaufgabe unter Zu verwendende Feeds die Option Feeds in meiner NuGet.config aus .
3. Geben Sie den Pfad zu an NuGet.config.
4. Entfernen Sie die /t:Restore;BuildOption aus der MSBuild-Task.

Weitere Informationen finden Sie hier .

Ich habe den Fehler erhalten, als ich in VS2017 ein Lambda im Punktnetzkern erstellt habe. Für mich hat es funktioniert, das Projekt zu entladen und wieder zu laden.

Führen Sie Ihren VS anschließend als Administrator in der Paketmanager-Konsole aus und führen Sie die Dotnet-Wiederherstellung aus.

Wenn Sie Dropbox zufällig verwenden, Conflictedsuchen Sie nach Dateinamen, suchen Sie in Ihrem Repo und löschen Sie alle in Konflikt stehenden Dateien.

Dies kann geschehen sein, wenn Sie die Dateien verschoben haben.

Ursache für diesen Fehler: Sie müssen das injizierte Nuget im Datei-Explorer entfernen. Lösung: Wenn Sie das Nuget in Ihrem System entfernt haben, entfernen Sie es von der folgenden Position. Wählen Sie Tool => Options => NuGet Package Manager => Package Sources und deaktivieren Sie die Option Microsoft Visual Studio Offline Packages

Dies hat bei mir funktioniert: Diese Paketquelle wurde hinzugefügt: Microsoft und .net https://www.nuget.org/api/v2/curated-feeds/microsoftdotnet/ Führen Sie dann "dotnet restore" in der Konsole aus

In meinem Fall hatte ich ein Problem mit den verfügbaren Paketquellen. Ich habe den lokalen Nuget-Repository-Ordner in einen neuen Pfad verschoben, ihn jedoch in den verfügbaren Nuget-Paketquellen nicht aktualisiert. Wenn ich das Pfadproblem behoben habe, aktualisieren Sie es in den verfügbaren Paketquellen. Danach funktionierte alles (Nuget-Wiederherstellung usw.) einwandfrei.

Für mich stellte sich heraus, dass es sich um ein Problem mit den Anmeldeinformationen der Nuget-Quelle handelte. Ich hatte kürzlich mein Kennwort für den Zugriff auf einen Nexus-Server geändert und Visual Studio verwendete immer noch das alte Kennwort, als ich versuchte, über den Windows-Anmeldeinformations-Manager auf ein Nuget auf diesem Server zuzugreifen. Um dies zu beheben, musste ich den Eintrag für diese veralteten Anmeldeinformationen im Anmeldeinformations-Manager löschen. Nach einer Nuget-Wiederherstellung wurde ich aufgefordert, ein Kennwort einzugeben, mit dem ich das neue Kennwort eingeben konnte, das erneut im Anmeldeinformations-Manager gespeichert wurde. Sie können über die cmd-Zeile mit CmdKey.exe auf den Anmeldeinformationsmanager zugreifen.

Versuchen Sie dies (es hat bei mir funktioniert):

• Führen Sie VS als Administrator aus
• Manuelles Update von NuGet auf die neueste Version
• Löschen Sie alle bin- und obj-Dateien im Projekt.
• Starten Sie VS neu
• Neu kompilieren

Sie können wählen für: Tools> NuGet Package Manager> Package Manager Console

Und dann laufen:

Dotnet-Wiederherstellung