Delen via

dotnet publish

Dit artikel is van toepassing op: ✔️ .NET 6 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>|<FILE>] [-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>] [-p|--property:<PROPERTYNAME>=<VALUE>]
    [-r|--runtime <RUNTIME_IDENTIFIER>]
    [--sc|--self-contained] [--no-self-contained]
    [-s|--source <SOURCE>] [--tl:[auto|on|off]]
    [--ucr|--use-current-runtime]
    [-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 het overzicht van het publiceren van .NET-toepassingen 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 publishen 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. Wanneer deze eigenschap is ingesteld op true, wordt de PublishSelfContained eigenschap impliciet ingesteld op true.

    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:

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 | FILE

Het project- of oplossings- of C#-bestand (op bestanden gebaseerde app) waarop moet worden gewerkt. Als er geen bestand is opgegeven, zoekt MSBuild in de huidige map naar een project of oplossing.

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

  • SOLUTION is het pad en de bestandsnaam van een oplossingsbestand (.sln of .slnx extensie) of het pad naar een map met een oplossingsbestand.

  • FILE is een argument toegevoegd in .NET 10. Het pad en de bestandsnaam van een app op basis van bestanden. Apps op basis van bestanden bevinden zich in één bestand dat is gebouwd en uitgevoerd zonder een bijbehorend projectbestand (.csproj). Zie C#-apps bouwen op basis van bestanden voor meer informatie.

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 op win-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 op net8.0 of een latere versie. De standaard buildconfiguratie is Debug 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.

  • --interactive

    Hiermee kan de opdracht stoppen en wachten op invoer of actie van de gebruiker. Bijvoorbeeld om de verificatie te voltooien.

  • --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 u dotnet 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 een PropertyGroup-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 een publish map onder de map die het projectbestand bevat.

  • --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 op linux-x64. Als u deze optie gebruikt, gebruikt u de optie -r|--runtime niet. Beschikbaar sinds .NET 6.

  • --sc|--self-contained

    Publiceer de .NET-runtime met uw toepassing, zodat de runtime niet hoeft te worden geïnstalleerd op de doelcomputer.

  • -p|--property:<PROPERTYNAME>=<VALUE>

    Hiermee stelt u een of meer MSBuild-eigenschappen in. Geef meerdere eigenschappen op die zijn gescheiden door puntkomma's of door de optie te herhalen:

    --property:<NAME1>=<VALUE1>;<NAME2>=<VALUE2>
--property:<NAME1>=<VALUE1> --property:<NAME2>=<VALUE2>

  • --no-self-contained

    Publiceer uw toepassing als een frameworkafhankelijke toepassing. Er moet een compatibele .NET-runtime worden geïnstalleerd op de doelcomputer om uw toepassing uit te voeren.

  • --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 het overzicht van het publiceren van .NET-toepassingen 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 Terminal Logger 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.

    Terminal Logger toont 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.

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

    Gebruik de huidige runtime als doelruntime.

  • -v|--verbosity <LEVEL>

    Hiermee stelt u het uitgebreidheidsniveau van de opdracht in. Toegestane waarden zijn q[uiet], m[inimal], n[ormal], d[etailed]en diag[nostic]. De standaardwaarde is minimal. Zie LoggerVerbosityvoor meer informatie.

  • --version-suffix <VERSION_SUFFIX>

    Definieert het versieachtervoegsel om het sterretje (*) te vervangen in het versieveld van het projectbestand.

  • -?|-h|--help

    Hiermee wordt een beschrijving afgedrukt van het gebruik van de opdracht.

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

  • Publiceer het op bestanden gebaseerde C#-programma app.cs in de huidige map:

    dotnet publish app.cs

    Ondersteuning voor programma's op basis van bestanden is toegevoegd in .NET SDK 10.0.100.

Zie ook

  • Last updated on