dotnet-återställning

Den här artikeln gäller för: ✔️ .NET 6 SDK och senare versioner

Namn

dotnet restore – Återställer beroenden och verktyg för ett projekt.

Sammanfattning

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

beskrivning

Ett .NET-projekt refererar vanligtvis till externa bibliotek i NuGet-paket som ger ytterligare funktioner. Dessa externa beroenden refereras till i projektfilen (.csproj eller .vbproj). När du kör dotnet restore kommandot använder .NET CLI NuGet för att söka efter dessa beroenden och ladda ned dem om det behövs. Det säkerställer också att alla beroenden som krävs av projektet är kompatibla med varandra och att det inte finns några konflikter mellan dem. När kommandot har slutförts är alla beroenden som krävs av projektet tillgängliga i en lokal cache och kan användas av .NET CLI för att skapa och köra programmet.

I de flesta fall behöver du inte uttryckligen dotnet restore använda kommandot, eftersom om en NuGet-återställning är nödvändig kör följande kommandon det implicit:

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

Ibland kan det vara obekvämt att köra den implicita NuGet-återställningen med dessa kommandon. Vissa automatiserade system, till exempel byggsystem, måste till exempel anropa dotnet restore explicit för att styra när återställningen sker så att de kan styra nätverksanvändningen. Om du vill förhindra implicit NuGet-återställning kan du använda --no-restore flaggan med något av dessa kommandon.

Ange feeds

För att återställa beroendena behöver NuGet feeds där paketen finns. Feeds tillhandahålls vanligtvis via konfigurationsfilen nuget.config . En standardkonfigurationsfil tillhandahålls när .NET SDK installeras. Gör något av följande för att ange ytterligare feeds:

• Skapa en egen nuget.config-fil i projektkatalogen. Mer information finns i Vanliga NuGet-konfigurationer och nuget.config-skillnader senare i den här artikeln.
• Använd dotnet nuget kommandon som dotnet nuget add source.

Du kan åsidosätta nuget.config-feeds med alternativet -s .

Information om hur du använder autentiserade feeds finns i Använda paket från autentiserade feeds.

Mappen Globala paket

För beroenden kan du ange var de återställde paketen placeras under återställningsåtgärden --packages med argumentet . Om det inte anges används nuGet-standardpaketcache, som finns i .nuget/packages katalogen i användarens hemkatalog på alla operativsystem. Till exempel /home/user1 på Linux eller C:\Users\user1 i Windows.

Projektspecifik verktygshantering

För projektspecifika verktyg dotnet restore återställer du först paketet där verktyget är packat och fortsätter sedan med att återställa verktygets beroenden enligt vad som anges i projektfilen.

skillnader i nuget.config

Beteendet för dotnet restore kommandot påverkas av inställningarna i nuget.config-filen , om det finns. Om du till exempel anger globalPackagesFolder i nuget.config placeras de återställde NuGet-paketen i den angivna mappen. Det här är ett alternativ till att ange alternativet --packages för dotnet restore kommandot. Mer information finns i referensen nuget.config.

Det finns tre specifika inställningar som dotnet restore ignorerar:

• bindingRedirects

  Bindningsomdirigeringar fungerar inte med <PackageReference> element och .NET stöder <PackageReference> endast element för NuGet-paket.

• lösning

  Den här inställningen är Visual Studio-specifik och gäller inte för .NET. .NET använder inte en packages.config fil och använder <PackageReference> i stället element för NuGet-paket.

• trustedSigners

  Stöd för verifiering av plattformsoberoende paketsignatur har lagts till i .NET 5.0.100 SDK.

Nedladdningar av arbetsbelastningsmanifest

När du kör det här kommandot initieras en asynkron bakgrundsnedladdning av annonseringsmanifest för arbetsbelastningar. Om nedladdningen fortfarande körs när det här kommandot är klart stoppas nedladdningen. Mer information finns i Annonseringsmanifest.

Argument

PROJECT | SOLUTION | FILE

Projektet eller lösningen eller C#-filen (filbaserad app) som ska användas. Om en fil inte har angetts söker MSBuild i den aktuella katalogen efter ett projekt eller en lösning.

• PROJECT är sökvägen och filnamnet för en C#-, F#- eller Visual Basic-projektfil eller sökvägen till en katalog som innehåller en C#-, F#- eller Visual Basic-projektfil.

• SOLUTION är sökvägen och filnamnet för en lösningsfil (.sln eller .slnx- filnamnstillägg) eller sökvägen till en katalog som innehåller en lösningsfil.

• FILE är ett argument som lagts till i .NET 10. Sökvägen och filnamnet för en filbaserad app. Filbaserade appar finns i en enda fil som skapas och körs utan motsvarande projektfil (.csproj). Mer information finns i Skapa filbaserade C#-appar.

Alternativ

• -a|--arch <ARCHITECTURE>

  Anger målarkitekturen. Det här är en kortsyntax för att ange Körtidsidentifierare (RID) där det angivna värdet kombineras med standard-RID. På en win-x64 dator anger du --arch x86 till exempel RID till win-x86. Om du använder det här alternativet ska du inte använda alternativet -r|--runtime . Tillgänglig sedan .NET 6 Förhandsversion 7.

• --configfile <FILE>

  NuGet-konfigurationsfilen (nuget.config) som ska användas. Om det anges används endast inställningarna från den här filen. Om det inte anges används hierarkin för konfigurationsfiler från den aktuella katalogen. Mer information finns i Vanliga NuGet-konfigurationer.

• --disable-build-servers

  Tvingar kommandot att ignorera alla beständiga byggservrar. Det här alternativet är ett konsekvent sätt att inaktivera all användning av cachelagring av versioner, vilket tvingar fram en version från grunden. En version som inte förlitar sig på cacheminnen är användbar när cacheminnena kan vara skadade eller felaktiga av någon anledning. Tillgänglig sedan .NET 7 SDK.

• --disable-parallel

  Inaktiverar återställning av flera projekt parallellt.

• --force

  Tvingar alla beroenden att lösas även om den senaste återställningen lyckades. Att ange den här flaggan är detsamma som att ta bort project.assets.json-filen.

• --force-evaluate

  Tvingar återställningen att omvärdera alla beroenden även om det redan finns en låsfil.

• --ignore-failed-sources

  Varna endast om misslyckade källor om det finns paket som uppfyller versionskravet.

• --interactive

  Tillåter att kommandot stoppar och väntar på användarens indata eller åtgärd. Till exempel för att slutföra autentiseringen.

• --lock-file-path <LOCK_FILE_PATH>

  Utdataplats där projektlåsfilen skrivs. Som standard är detta PROJECT_ROOT\packages.lock.json.

• --locked-mode

  Tillåt inte uppdatering av projektlåsfil.

• --no-dependencies

  När du återställer ett projekt med P2P-referenser (project-to-project) återställer rotprojektet och inte referenserna.

• --no-http-cache

  Inaktivera HTTP-cachelagring för paket.

• --os

  Anger måloperativsystemet (OS). Det här är en kortsyntax för att ange Runtime Identifier (RID), där det angivna värdet kombineras med standard-RID. På en win-x64 dator anger du --os linux till exempel RID till linux-x64.

  Introducerades i .NET SDK 10.0.100

• --packages <PACKAGES_DIRECTORY>

  Anger katalogen för återställde paket.

• -r|--runtime <RUNTIME_IDENTIFIER>

  Anger en körning för paketåterställningen. Detta används för att återställa paket för körningar som inte uttryckligen anges i taggen <RuntimeIdentifiers>i .csproj-filen . En lista över Runtime-identifierare (RID) finns i RID-katalogen.

• -s|--source <SOURCE>

  Anger URI:n för NuGet-paketkällan som ska användas under återställningsåtgärden. Den här inställningen åsidosätter alla källor som anges i nuget.config-filerna . Flera källor kan tillhandahållas genom att ange det här alternativet flera gånger.

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

  Använd den aktuella körningen som målkörning.

• --use-lock-file

  Gör att projektlåsfilen kan genereras och användas med återställning.

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

  Anger om Terminal Logger ska användas för byggutdata. Standardvärdet är auto, som först verifierar miljön innan du aktiverar terminalloggning. Miljökontrollen verifierar att terminalen kan använda moderna utdatafunktioner och inte använder en omdirigerad standardutdata innan den nya loggaren aktiveras. on hoppar över miljökontrollen och aktiverar terminalloggning. off hoppar över miljökontrollen och använder standardkonsolloggaren.

  TerminalLogger visar återställningsfasen följt av byggfasen. Under varje fas visas de pågående byggprojekten längst ned i terminalen. Varje projekt som skapar utdata både det MSBuild-mål som för närvarande skapas och hur lång tid som spenderas på det målet. Du kan söka efter den här informationen om du vill veta mer om bygget. När ett projekt är färdigt skrivs ett enda "build completed"-avsnitt som samlar in:

  • Namnet på det skapade projektet.
  • Målramverket (om det är flera mål).
  • Status för bygget.
  • Den primära utdatan för den versionen (som är hyperlänkad).
  • Diagnostik som genereras för projektet.

  Det här alternativet är tillgängligt från och med .NET 8.

• -v|--verbosity <LEVEL>

  Anger kommandots verbositetsnivå. Tillåtna värden är q[uiet], m[inimal], n[ormal], d[etailed]och diag[nostic]. Standardvärdet är minimal. Mer information finns i LoggerVerbosity.

• -?|-h|--help

  Skriver ut en beskrivning av hur du använder kommandot.

Exempel

• Återställa beroenden och verktyg för projektet i den aktuella katalogen:

  dotnet restore
  

• Återställa beroenden och verktyg för projektet som app1 finns i den angivna sökvägen:

  dotnet restore ./projects/app1/app1.csproj
  

• Återställ beroenden och verktyg för projektet i den aktuella katalogen med hjälp av den filsökväg som anges som källa:

  dotnet restore -s c:\packages\mypackages
  

• Återställ beroenden och verktyg för projektet i den aktuella katalogen med hjälp av de två filsökvägarna som tillhandahålls som källor:

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

• Återställ beroenden och verktyg för projektet i den aktuella katalogen med detaljerade utdata:

  dotnet restore --verbosity detailed
  

Granska säkerhetsrisker

Från och med .NET 8 dotnet restore innehåller NuGet-säkerhetsgranskning. Den här granskningsåtgärden genererar en rapport över säkerhetsrisker med det berörda paketnamnet, sårbarhetens allvarlighetsgrad och en länk till rekommendationen för mer information.

Om du vill avanmäla dig från säkerhetsgranskningen <NuGetAudit> anger du egenskapen MSBuild till false i projektfilen.

Om du vill hämta den kända datauppsättningen för säkerhetsrisker kontrollerar du att du har NuGet.org centrala registret definierat som en av dina paketkällor:

<packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>

Du kan konfigurera den nivå på vilken granskning misslyckas genom att ange <NuGetAuditLevel> egenskapen MSBuild. Möjliga värden är low, moderate, highoch critical. Om du till exempel bara vill se måttliga, höga och kritiska rekommendationer kan du ange egenskapen till moderate.

I .NET 8 och .NET 9 granskas endast direktpaketreferenser som standard. Från och med .NET 10 granskar NuGet både direkt - och transitiva paketreferenser som standard. Du kan ändra läget genom att ange <NuGetAuditMode> egenskapen MSBuild till direct eller all.

Mer information finns i Granska paketberoenden för säkerhetsrisker.