Freigeben über

dotnet restore

Dieser Artikel gilt für: ✔️ .NET 6 SDK und höhere Versionen

Name

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

Übersicht

dotnet restore [<PROJECT>|<SOLUTION>|<FILE>]
  [-a|--arch <ARCHITECTURE>] [--configfile <FILE>] [--disable-build-servers]
  [--disable-parallel] [-f|--force] [--force-evaluate]
  [--ignore-failed-sources] [--interactive] [--lock-file-path <LOCK_FILE_PATH>]
  [--locked-mode] [--no-dependencies] [--no-http-cache]
  [--os <OS>] [--packages <PACKAGES_DIRECTORY>]
  [-r|--runtime <RUNTIME_IDENTIFIER>] [-s|--source <SOURCE>]
  [--tl:[auto|on|off]] [--ucr|--use-current-runtime] [--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:

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 Der Überprüfung des signierten NuGet-Pakets.

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:

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.

  • Lösung

    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.

Workloadmanifestdownloads

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

PROJECT | SOLUTION | FILE

Die Projekt- oder Projektmappendatei oder C#-Datei (dateibasierte App), die ausgeführt werden soll. Wenn keine Datei angegeben ist, durchsucht MSBuild das aktuelle Verzeichnis für ein Projekt oder eine Projektmappe.

  • PROJECT ist der Pfad und Dateiname einer C#-, F#- oder Visual Basic-Projektdatei oder der Pfad zu einem Verzeichnis, das eine C#-, F#- oder Visual Basic-Projektdatei enthält.

  • SOLUTION ist der Pfad und Dateiname einer Lösungsdatei (.sln oder SLNX Erweiterung) oder der Pfad zu einem Verzeichnis, das eine Lösungsdatei enthält.

  • FILE ist ein In .NET 10 hinzugefügtes Argument. Der Pfad und Dateiname einer dateibasierten App. Dateibasierte Apps sind in einer einzelnen Datei enthalten, die ohne eine entsprechende Projektdatei (CSPROJ) erstellt und ausgeführt wird. Weitere Informationen finden Sie unter Erstellen dateibasierter C#-Apps.

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.

  • --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-dependencies

    Wenn Sie ein Projekt mit Projekt-zu-Projekt-Verweisen (P2P) wiederherstellen, stellen Sie das Stammprojekt wieder her und nicht die Verweise.

  • --no-http-cache

    Deaktivieren Sie die HTTP-Zwischenspeicherung für Pakete.

  • --os

    Gibt das Zielbetriebssystem an. Dies ist eine Abkürzungssyntax zum Festlegen des Runtime Identifier (RID), wobei der angegebene Wert mit dem Standardmäßigen RID kombiniert wird. Auf einem win-x64 Rechner wird beispielsweise durch die Angabe von --os linux der RID auf linux-x64 gesetzt.

    Eingeführt in .NET SDK 10.0.100

  • --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.

  • --ucr|--use-current-runtime

    Verwenden Sie die aktuelle Laufzeit als Ziellaufzeit.

  • --use-lock-file

    Ermöglicht das Generieren und Verwenden einer Projektsperrdatei bei der Wiederherstellung.

  • --tl:[auto|on|off]

    Gibt an, ob terminal logger 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.

    Terminal Logger zeigt Ihnen die Wiederherstellungsphase gefolgt von der Buildphase. 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.

  • -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.

  • -?|-h|--help

    Gibt eine Beschreibung zur Verwendung des Befehls aus.

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.

Zum Abrufen von Sicherheitsrisikodaten ab .NET 9 können auditSources Sie zusätzlich zu packageSources. Wenn keine Überwachungsquellen bereitgestellt werden, dotnet restore werden stattdessen Paketquellen verwendet. NuGet überwacht jede Quelle, solange die Quelle die VulnerabilityInfo Ressource bereitstellt.

Wenn Sie NuGet.org als Überwachungsquelle auflisten möchten, definieren Sie Folgendes in der dateinuget.config :

<configuration>
    <auditSources>
        <clear />
        <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
    </auditSources>
</configuration>

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.

In .NET 8 und .NET 9 werden standardmäßig nur direkte Paketverweise überwacht. Ab .NET 10 überwacht NuGet standardmäßig direkte und transitive Paketverweise. 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.

  • Last updated on