dotnet restore
Dieser Artikel gilt für: ✔️ .NET Core 3.1 SDK und höher
dotnet restore
: Stellt die Abhängigkeiten und Tools eines Projekts wieder her
dotnet restore [<ROOT>] [--configfile <FILE>] [--disable-build-servers]
[--disable-parallel]
[-f|--force] [--force-evaluate] [--ignore-failed-sources]
[--interactive] [--lock-file-path <LOCK_FILE_PATH>] [--locked-mode]
[--no-cache] [--no-dependencies] [--packages <PACKAGES_DIRECTORY>]
[-r|--runtime <RUNTIME_IDENTIFIER>] [-s|--source <SOURCE>]
[--tl:[auto|on|off]] [--use-current-runtime, --ucr [true|false]]
[--use-lock-file] [-v|--verbosity <LEVEL>]
dotnet restore -h|--help
Ein .NET-Projekt verweist in der Regel auf externe Bibliotheken in NuGet-Paketen, die zusätzliche Funktionen bereitstellen. Auf diese externen Abhängigkeiten wird in der Projektdatei (.csproj oder .vbproj) verwiesen. Wenn Sie den Befehl dotnet restore
ausführen, verwendet die .NET-CLI NuGet, um nach diesen Abhängigkeiten zu suchen und sie bei Bedarf herunterzuladen. Außerdem wird sichergestellt, dass alle für das Projekt erforderlichen Abhängigkeiten miteinander kompatibel sind und dass keine Konflikte zwischen ihnen auftreten. Nach Abschluss des Befehls sind alle für das Projekt erforderlichen Abhängigkeiten in einem lokalen Cache verfügbar und können von der .NET-CLI zum Erstellen und Ausführen der Anwendung verwendet werden.
In den meisten Fällen müssen Sie nicht explizit den Befehl dotnet restore
verwenden, da die folgenden Befehle implizit ausgeführt werden, wenn eine NuGet-Wiederherstellung erforderlich ist:
Manchmal kann es unpraktisch sein, die implizite NuGet-Wiederherstellung mit diesen Befehlen auszuführen. Zum Beispiel müssen einige automatisierte Systeme, wie etwa Buildsysteme, dotnet restore
explizit aufrufen, um zu kontrollieren, wann die Wiederherstellung stattfindet, damit sie die Netzwerknutzung steuern können. Sie können das Flag --no-restore
mit jedem dieser Befehle verwenden, um die implizite NuGet-Wiederherstellung zu verhindern.
Hinweis
Die Überprüfung des signierten Pakets bei Wiederherstellungsvorgängen erfordert einen Zertifikatstammspeicher, der für Codesignieren und Zeitstempel gültig ist. Weitere Informationen finden Sie unter Überprüfung von signierten NuGet-Paketen.
Zum Wiederherstellen der Abhängigkeiten benötigt NuGet die Feeds, wo sich die Pakete befinden. Feeds werden normalerweise über die nuget.config-Konfigurationsdatei bereitgestellt. Eine Standardkonfigurationsdatei wird bereitgestellt, wenn das .NET SDK installiert sind. Führen Sie eine der folgenden Schritte durch, um zusätzliche Feeds anzugeben:
- Erstellen Sie eine eigene nuget.config-Datei im Projektverzeichnis. Weitere Informationen finden Sie unter Gängige NuGet-Konfigurationen und unter Unterschiede bei „nuget.config“ weiter unten in diesem Artikel.
- Verwenden Sie
dotnet nuget
-Befehle wiedotnet nuget add source
.
Sie können die nuget.config- -Feeds mit der -s
-Option überschreiben.
Informationen zur Verwendung authentifizierter Feeds finden Sie unter Nutzen von Paketen aus authentifizierten Feeds.
Für Abhängigkeiten können Sie mithilfe des Arguments --packages
angeben, wo die wiederhergestellten Pakete während der Wiederherstellung platziert werden. Wenn nichts angegeben wurde, wird der Standardcache des NuGet-Pakets verwendet. Er befindet sich im Verzeichnis .nuget/packages
im Basisverzeichnis des Benutzers auf allen Betriebssystemen. Zum Beispiel /home/user1 unter Linux oder C:\Users\user1 unter Windows.
Für projektspezifische Tools stellt dotnet restore
zunächst das Paket wieder her, in dem sich das Tool befindet, und danach die Abhängigkeiten des Tools gemäß seiner Projektdatei.
Das Verhalten des Befehls dotnet restore
wird durch Einstellungen in der nuget.config-Datei (falls vorhanden) beeinflusst. Das Festlegen von globalPackagesFolder
in nuget.config platziert z. B. die wiederhergestellten NuGet-Pakete in den angegebenen Ordner. Dies ist eine Alternative zur Angabe der Option --packages
im dotnet restore
-Befehl. Weitere Informationen finden Sie in der Referenz zu „nuget.config“.
Es gibt drei bestimmte Einstellungen, die von dotnet restore
ignoriert werden:
-
Bindungsumleitungen funktionieren nicht mit
<PackageReference>
-Elementen, und .NET unterstützt nur<PackageReference>
-Elemente für NuGet-Pakete. -
Diese Einstellung ist spezifisch für Visual Studio und gilt nicht für .NET. .NET verwendet keine
packages.config
-Datei, aber stattdessen<PackageReference>
-Elemente für NuGet-Pakete. -
Die Unterstützung für die plattformübergreifende Überprüfung von Paketsignaturen wurde im .NET 5.0.100 SDK hinzugefügt.
Wenn Sie diesen Befehl ausführen, wird im Hintergrund ein asynchroner Download initiiert, der Ankündigungsmanifeste für Workloads herunterlädt. Wenn der Download noch ausgeführt wird, wenn der Befehl abgeschlossen ist, wird der Download angehalten. Weitere Informationen finden Sie unter Ankündigungsmanifeste.
ROOT
Optionaler Pfad zur wiederherzustellenden Projektdatei.
-a|--arch <ARCHITECTURE>
Legt die Zielarchitektur fest. Dies ist eine Kurzsyntax zum Setzen des Runtimebezeichners (RID), wobei der angegebene Wert mit dem Standard-RID kombiniert wird. Auf einem
win-x64
Rechner wird beispielsweise durch die Angabe von--arch x86
der RID aufwin-x86
gesetzt. Wenn Sie diese Option verwenden, dürfen Sie Option-r|--runtime
nicht verwenden. Verfügbar seit .NET 6 Preview 7.
--configfile <FILE>
Die zu verwendende NuGet-Konfigurationsdatei (nuget.config). Sofern angegeben, werden nur die Einstellungen aus dieser Datei verwendet. Falls nicht angegeben, wird die Hierarchie der Konfigurationsdateien aus dem aktuellen Verzeichnis verwendet. Weitere Informationen finden Sie unter Gängige NuGet-Konfigurationen.
--disable-build-servers
Erzwingt, dass der Befehl alle persistenten Buildserver ignoriert. Diese Option bietet eine konsistente Möglichkeit, die gesamte Verwendung von Buildcaches zu deaktivieren, wodurch die Neuerstellung eines Build von Grund auf erzwungen wird. Ein Build, der sich nicht auf Caches stützt, ist nützlich, wenn die Caches aus irgendeinem Grund beschädigt oder fehlerhaft sein können. Verfügbar ab dem .NET 7 SDK.
--disable-parallel
Deaktiviert paralleles Erstellen von mehreren Projekten.
--force
Erzwingt das Auflösen aller Abhängigkeiten, auch wenn die letzte Wiederherstellung erfolgreich war. Dieses Flag anzugeben, entspricht dem Löschen der Datei project.assets.json.
--force-evaluate
Erzwingt die Neubewertung aller Abhängigkeiten bei der Wiederherstellung, selbst wenn bereits eine Sperrdatei vorhanden ist.
-?|-h|--help
Gibt eine Beschreibung zur Verwendung des Befehls aus.
--ignore-failed-sources
Bei fehlerhaften Quellen nur warnen, wenn Pakete die Versionsanforderung erfüllen.
--interactive
Ermöglicht dem Befehl, anzuhalten und auf Benutzereingaben oder Aktionen zu warten. Beispielsweise, um die Authentifizierung abzuschließen.
--lock-file-path <LOCK_FILE_PATH>
Ausgabespeicherort, in den die Projektsperrdatei geschrieben wird. Standardmäßig ist dies PROJECT_ROOT\packages.lock.json.
--locked-mode
Lassen Sie keine Aktualisierung der Projektsperrdatei zu.
--no-cache
Gibt an, dass keine HTTP-Anforderungen zwischengespeichert werden
--no-dependencies
Wenn Sie ein Projekt mit Projekt-zu-Projekt-Verweisen (P2P) wiederherstellen, stellen Sie das Stammprojekt wieder her und nicht die Verweise.
--packages <PACKAGES_DIRECTORY>
Gibt das Verzeichnis für wiederhergestellte Pakete an.
-r|--runtime <RUNTIME_IDENTIFIER>
Gibt eine Laufzeit für die Wiederherstellung des Pakets an. Wird für das Wiederherstellen von Paketen für Laufzeiten verwendet, die nicht explizit im
<RuntimeIdentifiers>
-Tag in der .csproj-Datei aufgeführt sind. Eine Liste der Runtime-IDs (RIDs) finden Sie unter RID-Katalog.-s|--source <SOURCE>
Gibt den URI der NuGet-Paketquelle an, die während des Wiederherstellungsvorgangs zu verwenden ist. Diese Einstellung überschreibt alle Quellen, die in den nuget.config-Dateien angegeben sind. Es können mehrere Quellen bereitgestellt werden, indem diese Option mehrmals angegeben wird.
--tl:[auto|on|off]
Gibt an, ob die Terminalprotokollierung für die Buildausgabe verwendet werden soll. Der Standardwert ist
auto
, mit den zunächst die Umgebung überprüft wird, bevor die Terminalprotokollierung aktiviert wird. Die Umgebungsprüfung testet, ob das Terminal moderne Ausgabefeatures verwenden kann und keine umgeleitete Standardausgabe verwendet, bevor die neue Protokollierung aktiviert wird.on
überspringt die Umgebungsprüfung und aktiviert die Terminalprotokollierung.off
überspringt die Umgebungsprüfung und verwendet die Standardkonsolenprotokollierung.Die Terminalprotokollierung zeigt die Wiederherstellungsphase gefolgt von der Buildphase an. Während jeder Phase werden am unteren Rand des Terminals die derzeit erstellten Projekte angezeigt. Für jedes erstellte Projekt wird sowohl das MSBuild-Ziel für den Build als auch die Zeit ausgegeben, die für dieses Ziel aufgewendet wurde. Sie können diese Informationen durchsuchen, um mehr über den Build zu erfahren. Wenn die Erstellung eines Projekts abgeschlossen ist, wird ein einzelner Abschnitt „Build abgeschlossen“ geschrieben, in dem Folgendes erfasst wird:
- Der Name des erstellten Projekts
- Das Zielframework (bei mehreren Zielen)
- Der Status dieses Builds
- Die primäre Ausgabe dieses Builds (als Link)
- Alle für dieses Projekt generierten Diagnoseinformationen
Diese Option ist ab .NET 8 verfügbar.
--use-current-runtime, --ucr [true|false]
Legt den
RuntimeIdentifier
auf einen plattformübergreifendenRuntimeIdentifier
fest, der auf dem Computer basiert. Dies erfolgt implizit bei Eigenschaften, die einenRuntimeIdentifier
erfordern, z. B.SelfContained
,PublishAot
,PublishSelfContained
,PublishSingleFile
undPublishReadyToRun
. Wenn die Eigenschaft auf FALSE festgelegt ist, tritt diese implizite Auflösung nicht mehr auf.--use-lock-file
Ermöglicht das Generieren und Verwenden einer Projektsperrdatei bei der Wiederherstellung.
-v|--verbosity <LEVEL>
Legt den Ausführlichkeitsgrad für den Befehl fest. Zulässige Werte sind
q[uiet]
,m[inimal]
,n[ormal]
,d[etailed]
unddiag[nostic]
. Der Standardwert istminimal
. Weitere Informationen finden Sie unter LoggerVerbosity.
Wiederherstellen von Abhängigkeiten und Tools für das Projekt im aktuellen Verzeichnis:
.NET CLIdotnet restore
Wiederherstellen von Abhängigkeiten und Tools für das Projekt
app1
im vorgegebenen Pfad:.NET CLIdotnet restore ./projects/app1/app1.csproj
Wiederherstellen der Abhängigkeiten und Tools für das Projekt im aktuellen Verzeichnis mit dem bereitgestellten Dateipfad als Quelle:
.NET CLIdotnet restore -s c:\packages\mypackages
Wiederherstellen der Abhängigkeiten und Tools für das Projekt im aktuellen Verzeichnis mit den beiden bereitgestellten Dateipfaden als Quellen:
.NET CLIdotnet restore -s c:\packages\mypackages -s c:\packages\myotherpackages
Wiederherstellen von Abhängigkeiten und Tools für das Projekt im aktuellen Verzeichnis mit detaillierter Ausgabe:
.NET CLIdotnet restore --verbosity detailed
Ab .NET 8 dotnet restore
umfasst die NuGet-Sicherheitsüberwachung. Diese Überwachung erstellt einen Bericht zu Sicherheitsrisiken mit dem Namen des betroffenen Pakets, dem Schweregrad des Sicherheitsrisikos und einem Link zu Empfehlungen und weiteren Details.
Um die Sicherheitsüberwachung zu deaktivieren, legen Sie die <NuGetAudit>
MSBuild-Eigenschaft false
in Der Projektdatei fest.
Um das bekannte Sicherheitsrisiko-Dataset abzurufen, stellen Sie sicher, dass Sie die NuGet.org zentrale Registrierung als eine Ihrer Paketquellen definiert haben:
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
Sie können die Ebene konfigurieren, auf der die Überwachung Fehler ausgibt, indem Sie die MSBuild-Eigenschaft <NuGetAuditLevel>
festlegen. Mögliche Werte sind low
, moderate
, high
und critical
. Wenn Sie beispielsweise nur mittlere, hohe und kritische Empfehlungen anzeigen möchten, können Sie die Eigenschaft auf moderate
festlegen.
Ab .NET 9 überwacht NuGet standardmäßig direkte und transitive Paketverweise. In .NET 8 werden nur direkte Paketverweise überwacht. Sie können den Modus ändern, indem Sie die <NuGetAuditMode>
MSBuild-Eigenschaft auf direct
oder all
.
Weitere Informationen finden Sie unter Überwachen von Paketabhängigkeiten für Sicherheitsrisiken.
Feedback zu .NET
.NET ist ein Open Source-Projekt. Wählen Sie einen Link aus, um Feedback zu geben: