Udostępnij za pośrednictwem

dotnet restore

Artykuł dotyczy: ✔️ .NET 6 zestawu SDK i nowszych wersji

Nazwisko

dotnet restore — Przywraca zależności i narzędzia projektu.

Streszczenie

dotnet restore [<PROJECT>|<SOLUTION>|<FILE>]
  [-a|--arch <ARCHITECTURE>] [--artifacts-path <ARTIFACTS_DIR>] [--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

opis

Projekt .NET zwykle odwołuje się do bibliotek zewnętrznych w NuGet pakietów, które zapewniają dodatkowe funkcje. Do tych zależności zewnętrznych odwołuje się plik projektu (csproj lub vbproj). Po uruchomieniu polecenia dotnet restore interfejs wiersza polecenia .NET używa narzędzia NuGet do wyszukiwania tych zależności i pobierania ich w razie potrzeby. Gwarantuje również, że wszystkie zależności wymagane przez projekt są ze sobą zgodne i że nie występują konflikty między nimi. Po ukończeniu polecenia wszystkie zależności wymagane przez projekt są dostępne w lokalnej pamięci podręcznej i mogą być używane przez interfejs wiersza polecenia .NET do kompilowania i uruchamiania aplikacji.

W większości przypadków nie trzeba jawnie używać dotnet restore polecenia, ponieważ jeśli przywracanie NuGet jest konieczne, następujące polecenia są uruchamiane niejawnie:

Czasami może być niewygodne uruchomienie niejawnego przywracania NuGet za pomocą tych poleceń. Na przykład niektóre zautomatyzowane systemy, takie jak systemy kompilacji, muszą być dotnet restore wywoływane jawnie w celu kontrolowania czasu przywracania, aby mogły kontrolować użycie sieci. Aby zapobiec niejawnemu przywracaniu nuGet, możesz użyć --no-restore flagi z dowolnymi z tych poleceń.

Uwaga

Weryfikacja podpisanego pakietu podczas operacji przywracania wymaga magazynu głównego certyfikatu, który jest ważny zarówno w przypadku podpisywania kodu, jak i sygnatury czasowej. Aby uzyskać więcej informacji, zobacz Weryfikacja podpisanego pakietu NuGet.

Określanie kanałów informacyjnych

Aby przywrócić zależności, pakiet NuGet wymaga źródeł danych, w których znajdują się pakiety. Kanały informacyjne są zwykle dostarczane za pośrednictwem pliku konfiguracji nuget.config . Domyślny plik konfiguracji jest udostępniany podczas instalowania zestawu SDK .NET. Aby określić dodatkowe kanały informacyjne, wykonaj jedną z następujących czynności:

Możesz zastąpić źródła danych nuget.config opcją -s .

Aby uzyskać informacje o sposobie używania uwierzytelnionych źródeł danych, zobacz Korzystanie z pakietów z uwierzytelnionych źródeł danych.

Folder pakietów globalnych

W przypadku zależności można określić, gdzie przywrócone pakiety są umieszczane podczas operacji przywracania przy użyciu argumentu --packages . Jeśli nie zostanie określona, zostanie użyta domyślna pamięć podręczna pakietów NuGet, która znajduje się w .nuget/packages katalogu głównym użytkownika we wszystkich systemach operacyjnych. Na przykład /home/user1 w systemie Linux lub C:\Users\user1 w Windows.

narzędzia specyficzne dla Project

W przypadku narzędzi specyficznych dla projektu najpierw przywraca pakiet, dotnet restore w którym narzędzie jest pakowane, a następnie przechodzi do przywracania zależności narzędzia zgodnie z opisem w pliku projektu.

Różnice w pliku nuget.config

dotnet restore Zachowanie polecenia ma wpływ na ustawienia w pliku nuget.config, jeśli istnieje. Na przykład ustawienie w pliku globalPackagesFolder nuget.config umieszcza przywrócone pakiety NuGet w określonym folderze. Jest to alternatywa dla określenia --packages opcji w poleceniu dotnet restore . Aby uzyskać więcej informacji, zobacz dokumentację narzędzia nuget.config.

Istnieją trzy konkretne ustawienia, które dotnet restore ignorują:

  • bindingRedirects

    Przekierowania powiązań nie działają z elementami <PackageReference> i .NET obsługują tylko elementy <PackageReference> dla pakietów NuGet.

  • rozwiązanie

    To ustawienie jest Visual Studio specyficzne i nie ma zastosowania do .NET. .NET nie używa pliku packages.config, a zamiast tego używa elementów <PackageReference> dla pakietów NuGet.

  • trustedSigners

    Dodano obsługę weryfikacji podpisu pakietu międzyplatformowego w zestawie SDK .NET 5.0.100.

Pobieranie manifestu obciążenia

Po uruchomieniu tego polecenia inicjuje asynchroniczne pobieranie manifestów reklamowych dla obciążeń. Jeśli pobieranie jest nadal uruchomione po zakończeniu tego polecenia, pobieranie zostanie zatrzymane. Aby uzyskać więcej informacji, zobacz Manifesty reklamowe.

Argumenty

PROJECT | SOLUTION | FILE

Plik projektu lub rozwiązania lub C# (aplikacji opartej na plikach) do działania. Jeśli plik nie zostanie określony, program MSBuild przeszukuje bieżący katalog dla projektu lub rozwiązania.

  • PROJECT jest ścieżką i nazwą pliku projektu C#, F# lub Visual Basic albo ścieżką do katalogu zawierającego plik projektu C#, F# lub Visual Basic.

  • SOLUTION to ścieżka i nazwa pliku rozwiązania (.sln lub rozszerzenie .slnx) lub ścieżka do katalogu zawierającego plik rozwiązania.

  • FILE jest argumentem dodanym w .NET 10. Ścieżka i nazwa pliku aplikacji opartej na plikach. Aplikacje oparte na plikach znajdują się w jednym pliku, który jest kompilowany i uruchamiany bez odpowiedniego pliku projektu (csproj). Aby uzyskać więcej informacji, zobacz Tworzenie aplikacji języka C# opartych na plikach.

Opcje

  • -a|--arch <ARCHITECTURE>

    Określa architekturę docelową. Jest to skrócona składnia ustawiania identyfikatora środowiska uruchomieniowego (RID), gdzie podana wartość jest połączona z domyślnym identyfikatorem RID. Na przykład na maszynie win-x64 określenie --arch x86 ustawia identyfikator RID na win-x86wartość . Jeśli używasz tej opcji, nie używaj -r|--runtime opcji . Dostępne od .NET 6 (wersja zapoznawcza 7).

  • --artifacts-path <ARTIFACTS_DIR>

    Wszystkie pliki wyjściowe kompilacji z wykonanego polecenia zostaną umieszczone w podfolderach w określonej ścieżce oddzielonej przez projekt. Aby uzyskać więcej informacji, zobacz Artifacts Output Layout. Ta opcja i podana wartość muszą być jawnie kaskadowe w dowolnym dotnet poleceniu, które zależy od danych wyjściowych innego dotnet polecenia, na przykład w przypadku użycia dotnet build --no-restore i dotnet publish --no-build. Dostępne od .NET 8 zestawu SDK.

  • --configfile <FILE>

    Plik konfiguracji NuGet (nuget.config) do użycia. Jeśli zostanie określony, zostaną użyte tylko ustawienia z tego pliku. Jeśli nie zostanie określona, zostanie użyta hierarchia plików konfiguracji z bieżącego katalogu. Aby uzyskać więcej informacji, zobacz Typowe konfiguracje nuGet.

  • --disable-build-servers

    Wymusza zignorowanie jakichkolwiek trwałych serwerów kompilacji. Ta opcja zapewnia spójny sposób wyłączania całego użycia buforowania kompilacji, co wymusza kompilację od podstaw. Kompilacja, która nie opiera się na pamięciach podręcznych, jest przydatna, gdy pamięci podręczne mogą być uszkodzone lub niepoprawne z jakiegoś powodu. Dostępne od .NET 7 sdk.

  • --disable-parallel

    Wyłącza przywracanie wielu projektów równolegle.

  • --force

    Wymusza rozwiązanie wszystkich zależności, nawet jeśli ostatnie przywracanie zakończyło się pomyślnie. Określenie tej flagi jest takie samo jak usunięcie pliku project.assets.json .

  • --force-evaluate

    Wymusza przywrócenie w celu ponownego oceny wszystkich zależności, nawet jeśli plik blokady już istnieje.

  • --ignore-failed-sources

    Ostrzegaj tylko o źródłach, które zakończyły się niepowodzeniem, jeśli istnieją pakiety spełniające wymagania dotyczące wersji.

  • --interactive

    Umożliwia zatrzymanie polecenia i oczekiwanie na wprowadzenie lub działanie użytkownika. Na przykład w celu ukończenia uwierzytelniania.

  • --lock-file-path <LOCK_FILE_PATH>

    Lokalizacja wyjściowa, w której jest zapisywany plik blokady projektu. Domyślnie jest to PROJECT_ROOT\packages.lock.json.

  • --locked-mode

    Nie zezwalaj na aktualizowanie pliku blokady projektu.

  • --no-dependencies

    Podczas przywracania projektu przy użyciu odwołań typu project-to-project (P2P) przywraca projekt główny, a nie odwołania.

  • --no-http-cache

    Wyłącz buforowanie HTTP dla pakietów.

  • --os

    Określa docelowy system operacyjny. Jest to skrócona składnia ustawiania identyfikatora środowiska uruchomieniowego (RID), gdzie podana wartość jest połączona z domyślnym identyfikatorem RID. Na przykład na maszynie win-x64 określenie --os linux ustawia identyfikator RID na linux-x64wartość .

    Wprowadzono w zestawie .NET SDK 10.0.100

  • --packages <PACKAGES_DIRECTORY>

    Określa katalog dla przywróconych pakietów.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Określa środowisko uruchomieniowe przywracania pakietu. Służy to do przywracania pakietów dla środowisk uruchomieniowych, które nie zostały jawnie wymienione w tagu <RuntimeIdentifiers> w pliku csproj . Aby uzyskać listę identyfikatorów środowiska uruchomieniowego (RID), zobacz wykaz identyfikatorów RID.

  • -s|--source <SOURCE>

    Określa identyfikator URI źródła pakietu NuGet do użycia podczas operacji przywracania. To ustawienie zastępuje wszystkie źródła określone w plikach nuget.config . Wiele źródeł można udostępnić, określając tę opcję wiele razy.

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

    Użyj bieżącego środowiska uruchomieniowego jako docelowego środowiska uruchomieniowego.

  • --use-lock-file

    Umożliwia wygenerowanie i użycie pliku blokady projektu z przywracaniem.

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

    Określa, czy rejestrator terminalu ma być używany dla danych wyjściowych kompilacji. Wartość domyślna to auto, która najpierw weryfikuje środowisko przed włączeniem rejestrowania terminalu. Sprawdzanie środowiska sprawdza, czy terminal może korzystać z nowoczesnych funkcji wyjściowych i nie używa przekierowanych standardowych danych wyjściowych przed włączeniem nowego rejestratora. on Pomija sprawdzanie środowiska i włącza rejestrowanie terminalu. off Pomija sprawdzanie środowiska i używa domyślnego rejestratora konsoli.

    Rejestrator terminalu pokazuje fazę przywracania, po której następuje faza kompilacji. W każdej fazie obecnie projekty budowlane są wyświetlane w dolnej części terminalu. Każdy projekt, który tworzy, generuje dane wyjściowe zarówno docelowy programu MSBuild, który jest obecnie kompilowany, jak i ilość czasu spędzonego na tym obiekcie docelowym. Możesz wyszukać te informacje, aby dowiedzieć się więcej o kompilacji. Po zakończeniu kompilowania projektu zostanie napisana pojedyncza sekcja "ukończona kompilacja", która przechwytuje:

    • Nazwa utworzonego projektu.
    • Struktura docelowa (jeśli jest przeznaczona dla wielu celów).
    • Stan tej kompilacji.
    • Podstawowe dane wyjściowe tej kompilacji (która jest hiperlinkowana).
    • Każda diagnostyka wygenerowana dla tego projektu.

    Ta opcja jest dostępna od .NET 8.

  • -v|--verbosity <LEVEL>

    Ustawia poziom szczegółowości polecenia. Dozwolone wartości to q[uiet], , m[inimal]n[ormal], d[etailed], i diag[nostic]. Wartość domyślna to minimal. Aby uzyskać więcej informacji, zobacz LoggerVerbosity.

  • -?|-h|--help

    Wyświetla opis sposobu używania polecenia .

Przykłady

  • Przywróć zależności i narzędzia dla projektu w bieżącym katalogu:

    dotnet restore

  • Przywróć zależności i narzędzia dla app1 projektu znajdującego się w podanej ścieżce:

    dotnet restore ./projects/app1/app1.csproj

  • Przywróć zależności i narzędzia dla projektu w bieżącym katalogu przy użyciu ścieżki pliku podanej jako źródło:

    dotnet restore -s c:\packages\mypackages

  • Przywróć zależności i narzędzia dla projektu w bieżącym katalogu przy użyciu dwóch ścieżek plików podanych jako źródła:

    dotnet restore -s c:\packages\mypackages -s c:\packages\myotherpackages

  • Przywróć zależności i narzędzia dla projektu w bieżącym katalogu pokazujące szczegółowe dane wyjściowe:

    dotnet restore --verbosity detailed

Inspekcja pod kątem luk w zabezpieczeniach

Począwszy od .NET 8, dotnet restore obejmuje inspekcję zabezpieczeń NuGet. Ta inspekcja generuje raport luk w zabezpieczeniach z nazwą pakietu, ważnością luki w zabezpieczeniach i linkiem do porady, aby uzyskać więcej szczegółów.

Aby zrezygnować z inspekcji zabezpieczeń, ustaw <NuGetAudit> właściwość MSBuild na false w pliku projektu.

Aby uzyskać dane luk w zabezpieczeniach, począwszy od .NET 9, można użyć auditSources oprócz packageSources. Jeśli nie podano źródeł inspekcji, dotnet restore zamiast tego używa źródeł pakietów. Narzędzie NuGet przeprowadza inspekcję VulnerabilityInfodowolnego źródła, o ile źródło udostępnia zasób.

Aby wyświetlić listę NuGet.org jako źródło inspekcji, zdefiniuj następujące elementy w pliku nuget.config :

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

Można skonfigurować poziom, na którym inspekcja zakończy się niepowodzeniem, ustawiając <NuGetAuditLevel> właściwość MSBuild. Możliwe wartości to low, , moderatehighi critical. Jeśli na przykład chcesz wyświetlić tylko doradcy umiarkowane, wysokie i krytyczne, możesz ustawić właściwość na moderatewartość .

W .NET 8 i .NET 9 tylko direct odwołania do pakietów są domyślnie poddawane inspekcji. Począwszy od .NET 10, narzędzie NuGet przeprowadza inspekcję zarówno direct, jak i transitive odwołania do pakietów. Tryb można zmienić, ustawiając <NuGetAuditMode> właściwość MSBuild na direct lub all.

Aby uzyskać więcej informacji, zobacz Inspekcja zależności pakietów pod kątem luk w zabezpieczeniach.

  • Last updated on