dotnet publish
Dit artikel is van toepassing op: ✔️ .NET Core 3.1 SDK en latere versies
Naam
dotnet publish
: publiceert de toepassing en de bijbehorende afhankelijkheden naar een map voor implementatie naar een hostingsysteem.
Samenvatting
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
Beschrijving
dotnet publish
de toepassing compileert, de afhankelijkheden leest die zijn opgegeven in het projectbestand en publiceert de resulterende set bestanden naar een map. De uitvoer bevat de volgende assets:
- Il-code (Intermediate Language) in een assembly met een dll-bestand-extensie.
- Een .deps.json-bestand met alle afhankelijkheden van het project.
- Een .runtimeconfig.json-bestand dat de gedeelde runtime aangeeft die de toepassing verwacht, evenals andere configuratieopties voor de runtime (bijvoorbeeld type garbagecollection).
- De afhankelijkheden van de toepassing, die uit de NuGet-cache worden gekopieerd naar de uitvoermap.
De uitvoer van de dotnet publish
-opdracht is gereed voor implementatie naar een hostingsysteem (bijvoorbeeld een server, pc, Mac, laptop) voor uitvoering. Dit is de enige officieel ondersteunde manier om de toepassing voor te bereiden op implementatie. Afhankelijk van het type implementatie dat door het project wordt opgegeven, is de .NET-gedeelde runtime mogelijk al dan niet geïnstalleerd op het hostingsysteem. Zie .NET-apps publiceren met de .NET CLI-voor meer informatie.
Impliciete herstelbewerking
U hoeft dotnet restore
niet uit te voeren omdat deze impliciet wordt uitgevoerd door alle opdrachten waarvoor een herstelbewerking is vereist, zoals dotnet new
, dotnet build
, dotnet run
, dotnet test
, dotnet publish
en dotnet pack
. Als u impliciet herstellen wilt uitschakelen, gebruikt u de optie --no-restore
.
De dotnet restore
opdracht is nog steeds nuttig in bepaalde scenario's waarin expliciet herstellen zinvol is, zoals builds voor continue integratie in Azure DevOps Services of in buildsystemen die expliciet moeten worden beheerd wanneer het herstellen plaatsvindt.
Zie de dotnet restore
documentatievoor meer informatie over het beheren van NuGet-feeds.
MSBuild
De dotnet publish
opdracht roept MSBuild aan, die de Publish
doel aanroept. Als de eigenschap IsPublishable
is ingesteld op false
voor een bepaald project, kan het Publish
doel niet worden aangeroepen en wordt met de opdracht dotnet publish
alleen de impliciete dotnet-herstelbewerking uitgevoerd op het project.
Parameters die worden doorgegeven aan dotnet publish
worden doorgegeven aan MSBuild. De parameters -c
en -o
worden respectievelijk toegewezen aan de eigenschappen van MSBuild Configuration
en PublishDir
.
De opdracht dotnet publish
accepteert MSBuild-opties, zoals -p
voor het instellen van eigenschappen en -l
voor het definiëren van een logboekregistratie. U kunt bijvoorbeeld een MSBuild-eigenschap instellen met behulp van de notatie: -p:<NAME>=<VALUE>
.
.pubxml-bestanden
U kunt ook publicatie-gerelateerde eigenschappen instellen door te verwijzen naar een .pubxml--bestand. Bijvoorbeeld:
dotnet publish -p:PublishProfile=FolderProfile
In het voorgaande voorbeeld wordt het bestand FolderProfile.pubxml gebruikt dat is gevonden in de map <project_folder>/Properties/PublishProfiles. Als u een pad en bestandsextensie opgeeft bij het instellen van de eigenschap PublishProfile
, worden deze genegeerd. MSBuild kijkt standaard in de map Properties/PublishProfiles en gaat uit van de pubxml bestandsextensie. Als u het pad en de bestandsnaam inclusief extensie wilt opgeven, stelt u de eigenschap PublishProfileFullPath
in in plaats van de eigenschap PublishProfile
.
In het bestand .pubxml:
-
PublishUrl
wordt door Visual Studio gebruikt om het publicatiedoel aan te geven. -
PublishDir
wordt door de CLI gebruikt om het publicatiedoel aan te geven.
Als u wilt dat het scenario op alle plaatsen werkt, kunt u beide eigenschappen initialiseren op dezelfde waarde in het bestand .pubxml. Wanneer het GitHub-probleem dotnet/sdk#20931 is opgelost, hoeft slechts één van deze eigenschappen te worden ingesteld.
Sommige eigenschappen in het bestand .pubxml worden alleen door Visual Studio gehonoreerd en hebben geen effect op dotnet publish
. We werken eraan om de CLI meer in overeenstemming te brengen met het gedrag van Visual Studio. Maar sommige eigenschappen worden nooit gebruikt door de CLI. De CLI en Visual Studio doen beide het verpakkingsaspect van publicatie en dotnet/sdk#29817 plannen om ondersteuning toe te voegen voor meer eigenschappen die daaraan gerelateerd zijn. De CLI doet echter niet het automatiseringsaspect van de implementatie van publiceren en eigenschappen die zijn gerelateerd aan die niet worden ondersteund. De meest opvallende .pubxml eigenschappen die niet worden ondersteund door dotnet publish
zijn de volgende eigenschappen die van invloed zijn op de build:
LastUsedBuildConfiguration
Configuration
Platform
LastUsedPlatform
TargetFramework
TargetFrameworks
RuntimeIdentifier
RuntimeIdentifiers
MSBuild-eigenschappen
De volgende MSBuild-eigenschappen wijzigen de uitvoer van dotnet publish
.
PublishReadyToRun
Compileert toepassingsassembly's als ReadyToRun-indeling (R2R). R2R is een vorm van AOT-compilatie (ahead-of-time). Zie ReadyToRun-installatiekopieënvoor meer informatie.
Als u waarschuwingen wilt zien over ontbrekende afhankelijkheden die runtimefouten kunnen veroorzaken, gebruikt u
PublishReadyToRunShowWarnings=true
.U wordt aangeraden
PublishReadyToRun
op te geven in een publicatieprofiel in plaats van op de opdrachtregel.PublishSingleFile
Verpakt de app in een platformspecifiek uitvoerbaar bestand met één bestand. Zie het ontwerpdocument voor één bestand ontwerpdocument voor één bestandvoor meer informatie over publicatie van één bestand.
U wordt aangeraden deze optie op te geven in het projectbestand in plaats van op de opdrachtregel.
PublishTrimmed
Trimt ongebruikte bibliotheken om de implementatiegrootte van een app te verminderen bij het publiceren van een zelfstandig uitvoerbaar bestand. Zie Zelfstandige implementaties en uitvoerbare bestanden knippenvoor meer informatie. Beschikbaar sinds .NET 6 SDK.
U wordt aangeraden deze optie op te geven in het projectbestand in plaats van op de opdrachtregel.
Zie de volgende bronnen voor meer informatie:
- MSBuild-opdrachtregelreferentie
- Visual Studio-publicatieprofielen (.pubxml) voor ASP.NET Core-app-implementatie
- dotnet msbuild
Downloads van workloadmanifesten
Wanneer u deze opdracht uitvoert, wordt er een asynchrone achtergronddownload van reclamemanifesten voor workloads gestart. Als het downloaden nog steeds wordt uitgevoerd wanneer deze opdracht is voltooid, wordt het downloaden gestopt. Zie Reclamemanifestenvoor meer informatie.
Argumenten
PROJECT|SOLUTION
Het project of de oplossing die moet worden gepubliceerd.
PROJECT
is het pad en de bestandsnaam van een C#-, F#- of Visual Basic-projectbestand, of het pad naar een map die een C#-, F#- of Visual Basic-projectbestand bevat. Als de map niet is opgegeven, wordt deze standaard ingesteld op de huidige map.SOLUTION
is het pad en de bestandsnaam van een oplossingsbestand (.sln extensie) of het pad naar een map die een oplossingsbestand bevat. Als de map niet is opgegeven, wordt deze standaard ingesteld op de huidige map.
Opties
-a|--arch <ARCHITECTURE>
Hiermee geeft u de doelarchitectuur. Dit is een verkorte syntaxis voor het instellen van de Runtime Identifier (RID), waarbij de opgegeven waarde wordt gecombineerd met de standaard-RID. Als u bijvoorbeeld op een
win-x64
computer opgeeft--arch x86
de RID instelt opwin-x86
. Als u deze optie gebruikt, gebruikt u de optie-r|--runtime
niet. Beschikbaar sinds .NET 6 Preview 7.
--artifacts-path <ARTIFACTS_DIR>
Alle builduitvoerbestanden van de uitgevoerde opdracht worden weergegeven in submappen onder het opgegeven pad, gescheiden door project. Zie Indeling voor uitvoer van artefactenvoor meer informatie. Beschikbaar sinds .NET 8 SDK.
-c|--configuration <CONFIGURATION>
Definieert de buildconfiguratie. Als u ontwikkelt met de .NET 8 SDK of een latere versie, gebruikt de opdracht standaard de
Release
-configuratie voor projecten waarvan TargetFramework is ingesteld opnet8.0
of een latere versie. De standaard buildconfiguratie isDebug
voor eerdere versies van de SDK en voor eerdere doelframeworks. U kunt de standaardinstelling in projectinstellingen overschrijven of door deze optie te gebruiken. Zie voor meer informatie 'dotnet publish' gebruikmaakt van releaseconfiguratie en 'dotnet pack' gebruikmaakt van releaseconfiguratie.
--disable-build-servers
Hiermee wordt de opdracht gedwongen om permanente buildservers te negeren. Deze optie biedt een consistente manier om al het gebruik van buildcaching uit te schakelen, waardoor een volledig nieuwe build wordt afgemaakt. Een build die niet afhankelijk is van caches is handig wanneer de caches om een of andere reden beschadigd of onjuist zijn. Beschikbaar sinds .NET 7 SDK.
-f|--framework <FRAMEWORK>
Hiermee publiceert u de toepassing voor het opgegeven doelframework. U moet het doelframework opgeven in het projectbestand.
--force
Hiermee worden alle afhankelijkheden gedwongen om te worden opgelost, zelfs als de laatste herstelbewerking is geslaagd. Het opgeven van deze vlag is hetzelfde als het verwijderen van het project.assets.json-bestand.
-?|-h|--help
Hiermee wordt een beschrijving afgedrukt van het gebruik van de opdracht.
--interactive
Hiermee kan de opdracht stoppen en wachten op invoer of actie van de gebruiker. Bijvoorbeeld om de verificatie te voltooien. Beschikbaar sinds .NET Core 3.0 SDK.
--manifest <PATH_TO_MANIFEST_FILE>
Hiermee geeft u een of meer doelmanifesten te gebruiken om de set pakketten te knippen die met de app zijn gepubliceerd. Het manifestbestand maakt deel uit van de uitvoer van de opdracht
dotnet store
. Als u meerdere manifesten wilt opgeven, voegt u een--manifest
optie toe voor elk manifest.--no-build
Het project wordt niet gebouwd voordat het wordt gepubliceerd. Ook wordt de vlag
--no-restore
impliciet ingesteld.--no-dependencies
Negeert project-naar-projectverwijzingen en herstelt alleen het hoofdproject.
--nologo
De opstartbanner of het copyrightbericht wordt niet weergegeven.
--no-restore
Voert geen impliciete herstelbewerking uit bij het uitvoeren van de opdracht.
-o|--output <OUTPUT_DIRECTORY>
Hiermee geeft u het pad voor de uitvoermap.
Als dit niet is opgegeven, wordt standaard [project_file_folder]/bin/[configuration]/[framework]/publish/ voor binaire bestanden die afhankelijk zijn van een framework. De standaardinstelling is [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ voor een zelfstandig uitvoerbaar bestand.
Als de uitvoermap zich in een webproject in de projectmap bevindt, leiden opeenvolgende
dotnet publish
opdrachten tot geneste uitvoermappen. Als de projectmap bijvoorbeeld is myprojecten de uitvoermap publiceren myproject/publishis en udotnet publish
twee keer uitvoert, plaatst de tweede uitvoering inhoudsbestanden zoals .config en .json bestanden in myproject/publish/publish/publish. Als u het nesten van publicatiemappen wilt voorkomen, geeft u een publicatiemap op die niet rechtstreeks onder de projectmap, of sluit u de publicatiemap uit van het project. Als u een publicatiemap met de naam publishoutputwilt uitsluiten, voegt u het volgende element toe aan eenPropertyGroup
-element in het bestand .csproj:<DefaultItemExcludes>$(DefaultItemExcludes);publishoutput**</DefaultItemExcludes>
.NET 7.0.200 SDK en hoger
Als u de
--output
optie opgeeft bij het uitvoeren van deze opdracht op een oplossing, verzendt de CLI een waarschuwing (een fout in 7.0.200) vanwege de onduidelijke semantiek van het uitvoerpad. De optie--output
is niet toegestaan omdat alle uitvoer van alle gebouwde projecten wordt gekopieerd naar de opgegeven map, die niet compatibel is met projecten met meerdere doelgroepen, evenals projecten met verschillende versies van directe en transitieve afhankelijkheden. Zie optie--output
op oplossingsniveau niet meer geldig is voor build-gerelateerde opdrachtenvoor meer informatie..NET Core 3.x SDK en hoger
Als u een relatief pad opgeeft bij het publiceren van een project, is de gegenereerde uitvoermap relatief ten opzichte van de huidige werkmap, niet naar de locatie van het projectbestand.
Als u een relatief pad opgeeft bij het publiceren van een oplossing, gaat alle uitvoer voor alle projecten naar de opgegeven map ten opzichte van de huidige werkmap. Als u publicatie-uitvoer wilt maken, gaat u naar afzonderlijke mappen voor elk project door een relatief pad op te geven met behulp van de eigenschap msbuild
PublishDir
in plaats van de optie--output
.dotnet publish -p:PublishDir=.\publish
bijvoorbeeld publicatie-uitvoer voor elk project verzendt naar eenpublish
map onder de map die het projectbestand bevat..NET Core 2.x SDK
Als u een relatief pad opgeeft bij het publiceren van een project, is de gegenereerde uitvoermap relatief ten opzichte van de locatie van het projectbestand, niet naar de huidige werkmap.
Als u een relatief pad opgeeft bij het publiceren van een oplossing, gaat de uitvoer van elk project naar een afzonderlijke map ten opzichte van de locatie van het projectbestand. Als u een absoluut pad opgeeft bij het publiceren van een oplossing, gaat alle publicatie-uitvoer voor alle projecten naar de opgegeven map.
--os <OS>
Hiermee geeft u het doelbesturingssysteem (OS). Dit is een verkorte syntaxis voor het instellen van de Runtime Identifier (RID), waarbij de opgegeven waarde wordt gecombineerd met de standaard-RID. Als u bijvoorbeeld op een
win-x64
computer opgeeft--os linux
de RID instelt oplinux-x64
. Als u deze optie gebruikt, gebruikt u de optie-r|--runtime
niet. Beschikbaar sinds .NET 6.
--sc|--self-contained [true|false]
Hiermee publiceert u de .NET-runtime met uw toepassing, zodat de runtime niet hoeft te worden geïnstalleerd op de doelcomputer. De standaardinstelling is
true
als er een runtime-id is opgegeven en het project een uitvoerbaar project is (niet een bibliotheekproject). Zie .NET-toepassing publiceren en .NET-apps publiceren met de .NET CLI-voor meer informatie.Als deze optie wordt gebruikt zonder
true
offalse
op te geven, wordt de standaardwaardetrue
. Plaats in dat geval de oplossing of het projectargument niet direct na--self-contained
, omdattrue
offalse
in die positie wordt verwacht.--no-self-contained
Gelijk aan
--self-contained false
.--source <SOURCE>
De URI van de NuGet-pakketbron die moet worden gebruikt tijdens de herstelbewerking.
-r|--runtime <RUNTIME_IDENTIFIER>
Hiermee publiceert u de toepassing voor een bepaalde runtime. Zie de RID-catalogusvoor een lijst met runtime-id's (RID's). Zie .NET-toepassing publiceren en .NET-apps publiceren met de .NET CLI-voor meer informatie. Als u deze optie gebruikt, gebruikt u ook
--self-contained
of--no-self-contained
.
--tl:[auto|on|off]
Hiermee geeft u op of de terminallogger moet worden gebruikt voor de build-uitvoer. De standaardwaarde is
auto
, waarmee eerst de omgeving wordt geverifieerd voordat u terminallogboekregistratie inschakelt. De omgevingscontrole controleert of de terminal in staat is moderne uitvoerfuncties te gebruiken en geen omgeleide standaarduitvoer gebruikt voordat de nieuwe logger wordt ingeschakeld.on
de omgevingscontrole overslaat en terminallogboekregistratie inschakelt.off
de omgevingscontrole overslaat en de standaardconsolelogger gebruikt.De terminallogger toont u de herstelfase, gevolgd door de buildfase. Tijdens elke fase worden de huidige bouwprojecten onderaan de terminal weergegeven. Elk project dat wordt gebouwd, levert zowel het MSBuild-doel dat momenteel wordt gebouwd als de hoeveelheid tijd die aan dat doel is besteed. U kunt deze informatie doorzoeken voor meer informatie over de build. Wanneer een project klaar is met bouwen, wordt één sectie 'build completed' geschreven die het volgende vastlegt:
- De naam van het gebouwde project.
- Het doelframework (indien multi-targeted).
- De status van die build.
- De primaire uitvoer van die build (die is hyperlinked).
- Diagnostische gegevens die voor dat project worden gegenereerd.
Deze optie is beschikbaar vanaf .NET 8.
--use-current-runtime, --ucr [true|false]
Hiermee stelt u de
RuntimeIdentifier
in op een platform draagbareRuntimeIdentifier
op basis van uw computer. Dit gebeurt impliciet met eigenschappen waarvoor eenRuntimeIdentifier
is vereist, zoalsSelfContained
,PublishAot
,PublishSelfContained
,PublishSingleFile
enPublishReadyToRun
. Als de eigenschap is ingesteld op onwaar, vindt die impliciete resolutie niet meer plaats.
-v|--verbosity <LEVEL>
Hiermee stelt u het uitgebreidheidsniveau van de opdracht in. Toegestane waarden zijn
q[uiet]
,m[inimal]
,n[ormal]
,d[etailed]
endiag[nostic]
. De standaardwaarde isminimal
. Zie LoggerVerbosityvoor meer informatie.
--version-suffix <VERSION_SUFFIX>
Definieert het versieachtervoegsel om het sterretje (
*
) te vervangen in het versieveld van het projectbestand.
Voorbeelden
Maak een frameworkafhankelijke, platformafhankelijke binaire voor het project in de huidige map:
dotnet publish
Vanaf .NET Core 3.0 SDK maakt dit voorbeeld ook een frameworkafhankelijk uitvoerbare voor het huidige platform.
Maak een zelf-ingesloten uitvoerbare voor het project in de huidige map voor een specifieke runtime:
dotnet publish --runtime osx-x64
De RID moet zich in het projectbestand hebben.
Maak een frameworkafhankelijk uitvoerbare voor het project in de huidige map voor een specifiek platform:
dotnet publish --runtime osx-x64 --self-contained false
De RID moet zich in het projectbestand hebben. Dit voorbeeld is van toepassing op .NET Core 3.0 SDK en latere versies.
Publiceer het project in de huidige map voor een specifieke runtime en het doelframework:
dotnet publish --framework net8.0 --runtime osx-x64
Publiceer het opgegeven projectbestand:
dotnet publish ~/projects/app1/app1.csproj
Publiceer de huidige toepassing, maar herstel geen P2P-verwijzingen (project-to-project), alleen het hoofdproject tijdens de herstelbewerking:
dotnet publish --no-dependencies
Zie ook
- overzicht van .NET-toepassingspublicaties
- .NET-apps publiceren met de .NET CLI-
- Doelframeworks
-
RID-catalogus (Runtime Identifier) - een .NET-app containeriseren met dotnet
- Werken met macOS Catalina Notarization
- Mapstructuur van een gepubliceerde toepassing
- MSBuild-opdrachtregelreferentie
- Visual Studio-publicatieprofielen (.pubxml) voor ASP.NET Core-app-implementatie
- dotnet msbuild
- self-ingesloten implementaties knippen