dotnet publish

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

Namn

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>]
    [--artifacts-path <ARTIFACTS_DIR>]
    [-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:

• Kod för mellanliggande språk (IL) i en sammansättning med ett dll--tillägg.
• En .deps.json fil som innehåller alla beroenden för 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.

dotnet publish-kommandots 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 dotnet restore dokumentationen.

MSBuild

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

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

Kommandot dotnet publish accepterar MSBuild-alternativ, till exempel -p för att ange egenskaper och -l för att definiera en logger. Du kan till exempel ange en MSBuild-egenskap med hjälp av 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 anger egenskapen PublishProfile ignoreras de. MSBuild letar som standard i mappen Properties/PublishProfiles och förutsätter pubxml filnamnstillägget. Ange sökvägen och filnamnet inklusive tillägget genom att ange egenskapen PublishProfileFullPath i stället för egenskapen PublishProfile.

I filen .pubxml:

• 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 filen .pubxml. När GitHub-problemet dotnet/sdk#20931 har lösts behöver endast en av dessa egenskaper anges.

Vissa egenskaper i .pubxml- fil 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 planer på 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- egenskaper 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 för dotnet publish.

• 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 enfilspaket för.

  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-tillä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 Runtime Identifier (RID), där det angivna värdet kombineras med standard-RID. På en win-x64 dator anger du till exempel --arch x86 anger 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.

• --artifacts-path <ARTIFACTS_DIR>

  Alla build-utdatafiler från det körda kommandot kommer att gå i undermappar under den angivna sökvägen, avgränsade med projekt. Mer information finns i Artifacts Output Layout. Tillgänglig sedan .NET 8 SDK.

• -c|--configuration <CONFIGURATION>

  Definierar byggkonfigurationen. Om du utvecklar med .NET 8 SDK eller en senare version använder kommandot Release konfiguration som standard för projekt vars TargetFramework är inställt på net8.0 eller en senare version. Standardkonfigurationen för bygget ä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 utdata från kommandot dotnet store. 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 också implicit flaggan --no-restore.

• --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 [project_file_folder]/bin/[configuration]/[framework]/publish/ för en ramverksberoende körbar binärfil och plattformsoberoende binärfiler. Standardinställningen ä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 direkt under projektmappen eller exkluderar publiceringsmappen från projektet. Om du vill exkludera en publiceringsmapp med namnet publishoutputlägger du till följande element i ett PropertyGroup-element i filen .csproj:

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

  • .NET 7.0.200 SDK och senare

    Om du anger alternativet --output 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 tillåts inte eftersom alla utdata från alla byggda projekt kopieras till den angivna katalogen, som inte är kompatibel med projekt med flera mål, samt projekt som har olika versioner av direkta och transitiva beroenden. Mer information finns i lösningsnivå --output alternativet inte längre är 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 hjälp av egenskapen msbuild PublishDir i stället för alternativet --output. Till exempel skickar 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 Runtime Identifier (RID), där det angivna värdet kombineras med standard-RID. På en win-x64 dator anger du till exempel --os linux anger 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. Standardvärdet ä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 ange true eller falseär standardvärdet true. Placera i så fall inte lösningen eller projektargumentet direkt efter --self-contained, eftersom true eller false förväntas i den positionen.

• --no-self-contained

  Motsvarar --self-contained false.

• --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 Identifiers (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 du --self-contained eller --no-self-contained också.

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

  Anger om terminallogger 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]

  Anger RuntimeIdentifier till en bärbar plattform RuntimeIdentifier 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 binär 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örbara för den aktuella plattformen.

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

  dotnet publish --runtime osx-x64
  

  RID måste finnas i projektfilen.

• Skapa en ramverksberoende körbar 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

• .NET-programpubliceringsöversikt
• Publicera .NET-appar med .NET CLI-
• Målramverk
• RID-katalog (Runtime Identifier)
• Containerize a .NET app with dotnet publish
• Arbeta med macOS Catalina Notarization
• 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