dotnet restore

Dieser Artikel gilt für: ✔️ .NET Core 3.1 SDK und höher

Name

dotnet restore: Stellt die Abhängigkeiten und Tools eines Projekts wieder her

Übersicht

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

Beschreibung

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:

• dotnet new
• dotnet build
• dotnet build-server
• dotnet run
• dotnet test
• dotnet publish
• dotnet pack

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.

Angeben von Feeds

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 wie dotnet 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.

Ordner für globale Pakete

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.

Projektspezifische Tools

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.

Unterschiede bei „nuget.config“

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:

• bindingRedirects

  Bindungsumleitungen funktionieren nicht mit <PackageReference>-Elementen, und .NET unterstützt nur <PackageReference>-Elemente für NuGet-Pakete.

• solution

  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.

• trustedSigners

  Die Unterstützung für die plattformübergreifende Überprüfung von Paketsignaturen wurde im .NET 5.0.100 SDK hinzugefügt.

Workload manifest downloads

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.

Argumente

• ROOT

  Optionaler Pfad zur wiederherzustellenden Projektdatei.

Optionen

• -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 auf win-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übergreifenden RuntimeIdentifier fest, der auf dem Computer basiert. Dies erfolgt implizit bei Eigenschaften, die einen RuntimeIdentifiererfordern, z. B. SelfContained, PublishAot, PublishSelfContained, PublishSingleFile und PublishReadyToRun. 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] und diag[nostic]. Der Standardwert ist minimal. Weitere Informationen finden Sie unter LoggerVerbosity.

Beispiele

• Wiederherstellen von Abhängigkeiten und Tools für das Projekt im aktuellen Verzeichnis:

  dotnet restore
  

• Wiederherstellen von Abhängigkeiten und Tools für das Projekt app1 im vorgegebenen Pfad:

  dotnet restore ./projects/app1/app1.csproj
  

• Wiederherstellen der Abhängigkeiten und Tools für das Projekt im aktuellen Verzeichnis mit dem bereitgestellten Dateipfad als Quelle:

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

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

  dotnet restore --verbosity detailed
  

Überwachen auf Sicherheitsrisiken

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.