dotnet publish

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

Name

dotnet publish – Publicerar programmet och dess beroenden till en mapp för distribution till ett värdsystem.

Sammanfattning

dotnet publish [<PROJECT>|<SOLUTION>] [-a|--arch <ARCHITECTURE>]
    [-c|--configuration <CONFIGURATION>] [--disable-build-servers]
    [-f|--framework <FRAMEWORK>] [--force] [--interactive]
    [--manifest <PATH_TO_MANIFEST_FILE>] [--no-build] [--no-dependencies]
    [--no-restore] [--nologo] [-o|--output <OUTPUT_DIRECTORY>]
    [--os <OS>] [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--sc|--self-contained [true|false]] [--no-self-contained]
    [-s|--source <SOURCE>] [--tl:[auto|on|off]]
    [--use-current-runtime, --ucr [true|false]]
    [-v|--verbosity <LEVEL>] [--version-suffix <VERSION_SUFFIX>]

dotnet publish -h|--help

beskrivning

dotnet publish kompilerar programmet, läser igenom dess beroenden som anges i projektfilen och publicerar den resulterande uppsättningen filer till en katalog. Utdata innehåller följande tillgångar:

• Il-kod (Intermediate Language) i en sammansättning med ett dll-tillägg .
• En .deps.json fil som innehåller alla beroenden i projektet.
• En .runtimeconfig.json fil som anger den delade körning som programmet förväntar sig, samt andra konfigurationsalternativ för körningen (till exempel typ av skräpinsamling).
• Programmets beroenden, som kopieras från NuGet-cachen till utdatamappen.

Kommandots dotnet publish utdata är redo för distribution till ett värdsystem (till exempel en server, PC, Mac, bärbar dator) för körning. Det är det enda sättet som stöds officiellt att förbereda programmet för distribution. Beroende på vilken typ av distribution som projektet anger kan värdsystemet ha .NET-delad körning installerad på det. Mer information finns i Publicera .NET-appar med .NET CLI.

Implicit återställning

Du behöver inte köra dotnet restore eftersom den körs implicit av alla kommandon som kräver en återställning, till exempel dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishoch dotnet pack. Om du vill inaktivera implicit återställning använder du alternativet --no-restore .

Kommandot dotnet restore är fortfarande användbart i vissa scenarier där det är meningsfullt att uttryckligen återställa, till exempel kontinuerliga integreringsversioner i Azure DevOps Services eller i byggsystem som uttryckligen behöver styra när återställningen sker.

Information om hur du hanterar NuGet-feeds finns i dokumentationendotnet restore.

MSBuild

Kommandot dotnet publish anropar MSBuild, som anropar Publish målet. Om egenskapen IsPublishable är inställd på false för ett visst projekt Publish kan målet inte anropas, och dotnet publish kommandot kör bara den implicita dotnet-återställningen i projektet.

Alla parametrar som skickas till dotnet publish skickas till MSBuild. Parametrarna -c och -o mappas till MSBuilds Configuration respektive PublishDir egenskaper.

Kommandot dotnet publish accepterar MSBuild-alternativ, till exempel -p för att ange egenskaper och -l definiera en logger. Du kan till exempel ange en MSBuild-egenskap med formatet : -p:<NAME>=<VALUE>.

.pubxml-filer

Du kan också ange publiceringsrelaterade egenskaper genom att referera till en .pubxml-fil . Till exempel:

dotnet publish -p:PublishProfile=FolderProfile

I föregående exempel används filen FolderProfile.pubxml som finns i <mappen project_folder>/Properties/PublishProfiles. Om du anger en sökväg och filnamnstillägg när du PublishProfile anger egenskapen ignoreras de. MSBuild söker som standard i mappen Egenskaper/PublishProfiles och förutsätter filnamnstillägget pubxml . Ange sökvägen och filnamnet inklusive tillägget genom att PublishProfileFullPath ange egenskapen i stället för egenskapen PublishProfile .

I .pubxml-filen:

• PublishUrl används av Visual Studio för att ange publiceringsmålet.
• PublishDir används av CLI för att ange publiceringsmålet.

Om du vill att scenariot ska fungera på alla platser kan du initiera båda dessa egenskaper till samma värde i .pubxml-filen . När GitHub-problemet dotnet/sdk#20931 har lösts behöver endast en av dessa egenskaper anges.

Vissa egenskaper i .pubxml-filen respekteras endast av Visual Studio och har ingen effekt på dotnet publish. Vi arbetar med att anpassa CLI mer till Visual Studios beteende. Men vissa egenskaper kommer aldrig att användas av CLI. BÅDE CLI och Visual Studio utför paketeringsaspekten för publicering, och dotnet/sdk#29817 planerar att lägga till stöd för fler egenskaper relaterade till detta. Men CLI utför inte distributionsautomatiseringsaspekten för publicering och egenskaper som är relaterade till som inte stöds. De mest anmärkningsvärda .pubxml-egenskaperna som inte stöds av dotnet publish är följande som påverkar bygget:

• LastUsedBuildConfiguration
• Configuration
• Platform
• LastUsedPlatform
• TargetFramework
• TargetFrameworks
• RuntimeIdentifier
• RuntimeIdentifiers

MSBuild-egenskaper

Följande MSBuild-egenskaper ändrar utdata dotnet publishför .

• PublishReadyToRun

  Kompilerar programsammansättningar som R2R-format (ReadyToRun). R2R är en form av AOT-kompilering (ahead-of-time). Mer information finns i ReadyToRun-avbildningar.

  Om du vill se varningar om saknade beroenden som kan orsaka körningsfel använder du PublishReadyToRunShowWarnings=true.

  Vi rekommenderar att du anger PublishReadyToRun i en publiceringsprofil i stället för på kommandoraden.

• PublishSingleFile

  Paketera appen i en plattformsspecifik körbar fil. Mer information om publicering med en fil finns i designdokumentet för en fil.

  Vi rekommenderar att du anger det här alternativet i projektfilen i stället för på kommandoraden.

• PublishTrimmed

  Trimmar oanvända bibliotek för att minska distributionsstorleken för en app när du publicerar en fristående körbar fil. Mer information finns i Trimma fristående distributioner och körbara filer. Tillgänglig sedan .NET 6 SDK.

  Vi rekommenderar att du anger det här alternativet i projektfilen i stället för på kommandoraden.

Mer information finns i följande resurser:

• MSBuild-kommandoradsreferens
• Visual Studio publicerar profiler (.pubxml) för ASP.NET Core-appdistribution
• dotnet msbuild

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

  Projektet eller lösningen som ska publiceras.

  • 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. Om katalogen inte har angetts är den som standard den aktuella katalogen.

  • SOLUTION är sökvägen och filnamnet för en lösningsfil (.sln filnamnstillägget) eller sökvägen till en katalog som innehåller en lösningsfil. Om katalogen inte har angetts är den som standard den aktuella katalogen.

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.

• -c|--configuration <CONFIGURATION>

  Definierar byggkonfigurationen. Om du utvecklar med .NET 8 SDK eller en senare version använder kommandot konfigurationen Release som standard för projekt vars TargetFramework är inställt på net8.0 eller en senare version. Standardkonfigurationen är Debug för tidigare versioner av SDK och för tidigare målramverk. Du kan åsidosätta standardinställningen i projektinställningar eller med det här alternativet. Mer information finns i "dotnet publish" använder versionskonfiguration och "dotnet pack" använder versionskonfiguration.

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

• -f|--framework <FRAMEWORK>

  Publicerar programmet för det angivna målramverket. Du måste ange målramverket i projektfilen.

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

• -?|-h|--help

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

• --interactive

  Tillåter att kommandot stoppar och väntar på användarens indata eller åtgärd. Till exempel för att slutföra autentiseringen. Tillgänglig sedan .NET Core 3.0 SDK.

• --manifest <PATH_TO_MANIFEST_FILE>

  Anger ett eller flera målmanifest som ska användas för att trimma uppsättningen paket som publicerats med appen. Manifestfilen är en del av kommandots dotnet storeutdata. Om du vill ange flera manifest lägger du till ett --manifest alternativ för varje manifest.

• --no-build

  Skapar inte projektet innan det publiceras. Den anger --no-restore också implicit flaggan.

• --no-dependencies

  Ignorerar projekt-till-projekt-referenser och återställer bara rotprojektet.

• --nologo

  Visar inte startbanderollen eller upphovsrättsmeddelandet.

• --no-restore

  Kör inte en implicit återställning när kommandot körs.

• -o|--output <OUTPUT_DIRECTORY>

  Anger sökvägen för utdatakatalogen.

  Om det inte anges är standardvärdet [project_file_folder]/bin/[configuration]/[framework]/publish/ för en ramverksberoende körbar binärfil och plattformsoberoende binärfiler. Standardvärdet är [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ för en fristående körbar fil.

  Om utdatamappen finns i projektmappen i ett webbprojekt resulterar efterföljande dotnet publish kommandon i kapslade utdatamappar. Om projektmappen till exempel är myproject och publiceringsutdatamappen är myproject/publish, och du kör dotnet publish två gånger, placerar den andra körningen innehållsfiler som .config och .json filer i myproject/publish/publish. Om du vill undvika kapsling av publiceringsmappar anger du en publiceringsmapp som inte finns direkt under projektmappen eller exkluderar publiceringsmappen från projektet. Om du vill exkludera en publiceringsmapp med namnet publishoutput lägger du till följande element i ett PropertyGroup element i .csproj-filen :

  <DefaultItemExcludes>$(DefaultItemExcludes);publishoutput**</DefaultItemExcludes>
  

  • .NET 7.0.200 SDK och senare

    Om du anger --output alternativet när du kör det här kommandot på en lösning genererar CLI en varning (ett fel i 7.0.200) på grund av den oklara semantiken i utdatasökvägen. Alternativet --output är inte tillåtet eftersom alla utdata från alla inbyggda projekt kopieras till den angivna katalogen, som inte är kompatibel med flera målprojekt, samt projekt som har olika versioner av direkta och transitiva beroenden. Mer information finns i Alternativet på lösningsnivå --output är inte längre giltigt för build-relaterade kommandon.

  • .NET Core 3.x SDK och senare

    Om du anger en relativ sökväg när du publicerar ett projekt är den genererade utdatakatalogen relativ till den aktuella arbetskatalogen, inte till projektfilens plats.

    Om du anger en relativ sökväg när du publicerar en lösning hamnar alla utdata för alla projekt i den angivna mappen i förhållande till den aktuella arbetskatalogen. Om du vill att publiceringsutdata ska gå till separata mappar för varje projekt anger du en relativ sökväg med egenskapen msbuild PublishDir i stället för alternativet --output . Skickar till exempel dotnet publish -p:PublishDir=.\publish publiceringsutdata för varje projekt till en publish mapp under mappen som innehåller projektfilen.

  • .NET Core 2.x SDK

    Om du anger en relativ sökväg när du publicerar ett projekt är den genererade utdatakatalogen relativ till projektfilens plats, inte till den aktuella arbetskatalogen.

    Om du anger en relativ sökväg när du publicerar en lösning hamnar varje projekts utdata i en separat mapp i förhållande till projektfilens plats. Om du anger en absolut sökväg när du publicerar en lösning hamnar alla publiceringsutdata för alla projekt i den angivna mappen.

• --os <OS>

  Anger måloperativsystemet (OS). 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 --os linux till exempel RID till linux-x64. Om du använder det här alternativet ska du inte använda alternativet -r|--runtime . Tillgänglig sedan .NET 6.

• --sc|--self-contained [true|false]

  Publicerar .NET-körningen med ditt program så att körningen inte behöver installeras på måldatorn. Standard är true om en körningsidentifierare har angetts och projektet är ett körbart projekt (inte ett biblioteksprojekt). Mer information finns i .NET-programpublicering och Publicera .NET-appar med .NET CLI.

  Om det här alternativet används utan att true ange eller falseär truestandardvärdet . Placera i så fall inte lösningen eller projektargumentet omedelbart efter --self-contained, eftersom true eller false förväntas i den positionen.

• --no-self-contained

  --self-contained falseMotsvarar .

• --source <SOURCE>

  URI:n för NuGet-paketkällan som ska användas under återställningsåtgärden.

• -r|--runtime <RUNTIME_IDENTIFIER>

  Publicerar programmet för en viss körning. En lista över Runtime-identifierare (RID) finns i RID-katalogen. Mer information finns i .NET-programpublicering och Publicera .NET-appar med .NET CLI. Om du använder det här alternativet använder --self-contained du eller --no-self-contained också.

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

  Anger om terminalloggaren 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.

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

• --use-current-runtime, --ucr [true|false]

  RuntimeIdentifier Anger till en bärbar RuntimeIdentifier plattform baserat på en av dina datorer. Detta sker implicit med egenskaper som kräver en RuntimeIdentifier, till exempel SelfContained, PublishAot, PublishSelfContained, PublishSingleFileoch PublishReadyToRun. Om egenskapen är inställd på false sker inte längre den implicita lösningen.

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

• --version-suffix <VERSION_SUFFIX>

  Definierar versionssuffixet för att ersätta asterisken (*) i versionsfältet i projektfilen.

Exempel

• Skapa en ramverksberoende plattformsoberoende binärfil för projektet i den aktuella katalogen:

  dotnet publish
  

  Från och med .NET Core 3.0 SDK skapar det här exemplet även en ramverksberoende körbar fil för den aktuella plattformen.

• Skapa en fristående körbar fil för projektet i den aktuella katalogen för en specifik körning:

  dotnet publish --runtime osx-x64
  

  RID måste finnas i projektfilen.

• Skapa en ramverksberoende körbar fil för projektet i den aktuella katalogen för en specifik plattform:

  dotnet publish --runtime osx-x64 --self-contained false
  

  RID måste finnas i projektfilen. Det här exemplet gäller för .NET Core 3.0 SDK och senare versioner.

• Publicera projektet i den aktuella katalogen för ett specifikt körnings- och målramverk:

  dotnet publish --framework net8.0 --runtime osx-x64
  

• Publicera den angivna projektfilen:

  dotnet publish ~/projects/app1/app1.csproj
  

• Publicera det aktuella programmet men återställ inte P2P-referenser (project-to-project), bara rotprojektet under återställningsåtgärden:

  dotnet publish --no-dependencies
  

Se även

• Översikt över publicering av .NET-program
• Publicera .NET-appar med .NET CLI
• Målramverk
• Rid-katalog (Runtime Identifier)
• Containerisera en .NET-app med dotnet publish
• Arbeta med macOS Catalina-notarisering
• Katalogstruktur för ett publicerat program
• MSBuild-kommandoradsreferens
• Visual Studio publicerar profiler (.pubxml) för ASP.NET Core-appdistribution
• dotnet msbuild
• Trimma fristående distributioner