dotnet publish

  • Artikel

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 compileert de toepassing, leest de bijbehorende afhankelijkheden die zijn opgegeven in het projectbestand en publiceert de resulterende set bestanden naar een map. De uitvoer bevat de volgende assets:

  • Tussentaalcode (IL) in een assembly met een DLL-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 niet uit te voeren dotnet restore omdat deze impliciet wordt uitgevoerd door alle opdrachten waarvoor een herstelbewerking moet worden uitgevoerd, zoals dotnet new, dotnet build, , dotnet run, dotnet test, , en dotnet publish.dotnet pack Als u impliciete herstel wilt uitschakelen, gebruikt u de --no-restore optie.

De dotnet restore opdracht is nog steeds nuttig in bepaalde scenario's waarbij het expliciet herstellen zinvol is, zoals builds voor continue integratie in Azure DevOps Services of in buildsystemen die expliciet moeten worden beheerd wanneer de herstelbewerking plaatsvindt.

Zie de dotnet restore documentatie voor informatie over het beheren van NuGet-feeds.

MSBuild

Met de dotnet publish opdracht wordt MSBuild aangeroepen, die het Publish doel aanroept. Als de IsPublishable eigenschap is ingesteld false op voor een bepaald project, kan het Publish doel niet worden aangeroepen en wordt met de dotnet publish opdracht alleen de impliciete dotnet-herstelbewerking op het project uitgevoerd.

Alle parameters die aan worden doorgegeven dotnet publish , worden doorgegeven aan MSBuild. De -c parameters worden -o respectievelijk toegewezen aan MSBuild Configuration en PublishDir eigenschappen.

De dotnet publish opdracht accepteert MSBuild-opties, zoals -p voor het instellen van eigenschappen en -l het definiëren van een logboekregistratie. U kunt bijvoorbeeld een MSBuild-eigenschap instellen met behulp van de indeling: -p:<NAME>=<VALUE>.

.pubxml-bestanden

U kunt ook publicatie-gerelateerde eigenschappen instellen door te verwijzen naar een .pubxml-bestand . Voorbeeld:

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 PublishProfile eigenschap, worden deze genegeerd. MSBuild kijkt standaard in de map Properties/PublishProfiles en gaat ervan uit dat de pubxml-bestandsextensie wordt gebruikt. Als u het pad en de bestandsnaam inclusief extensie wilt opgeven, stelt u de PublishProfileFullPath eigenschap in in plaats van de PublishProfile eigenschap.

In het .pubxml-bestand :

  • 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 .pubxml-bestand . Als het probleem met GitHub dotnet/sdk#20931 is opgelost, hoeft slechts één van deze eigenschappen te worden ingesteld.

Sommige eigenschappen in het .pubxml-bestand 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 hieraan 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ën voor meer informatie.

    Als u waarschuwingen wilt zien over ontbrekende afhankelijkheden die runtimefouten kunnen veroorzaken, gebruikt u PublishReadyToRunShowWarnings=true.

    U wordt aangeraden in een publicatieprofiel op te geven PublishReadyToRun in plaats van op de opdrachtregel.

  • PublishSingleFile

    Verpakt de app in een platformspecifiek uitvoerbaar bestand met één bestand. Zie het ontwerpdocument met één bestandsbundel voor meer informatie over het publiceren 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 Self-Ingesloten implementaties en uitvoerbare bestanden knippen voor meer informatie. Beschikbaar sinds .NET 6 SDK.

    U wordt aangeraden deze optie op te geven in het projectbestand in plaats van op de opdrachtregel.

Voor meer informatie raadpleegt u de volgende bronnen:

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 Reclamemanifesten voor 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-id (RID), waarbij de opgegeven waarde wordt gecombineerd met de standaard-RID. Als u bijvoorbeeld op een win-x64 computer opgeeft --arch x86 , wordt de RID ingesteld op win-x86. Als u deze optie gebruikt, gebruikt u de -r|--runtime optie 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 De indeling Artefacten-uitvoer voor 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 net8.0 op 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 'dotnet publish' maakt gebruik van releaseconfiguratie en dotnet pack maakt gebruik 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 meerdere doelmanifesten op die moeten worden gebruikt om de set pakketten te knippen die met de app zijn gepubliceerd. Het manifestbestand maakt deel uit van de uitvoer van de dotnet store opdracht. 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. De vlag wordt ook impliciet ingesteld --no-restore .

  • --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 deze standaard ingesteld op [project_file_folder]/bin/[configuration]/[framework]/publish/ voor een frameworkafhankelijk uitvoerbaar bestand en binaire bestanden op meerdere platforms. Deze wordt standaard ingesteld op [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ voor een zelfstandig uitvoerbaar bestand.

    Als de uitvoermap zich in een webproject in de projectmap bevindt, resulteren opeenvolgende dotnet publish opdrachten in geneste uitvoermappen. Als de projectmap bijvoorbeeld myproject is en de uitvoermap publiceren myproject/publish is en u twee keer uitvoertdotnet publish, worden inhoudsbestanden zoals .config en .json bestanden in myproject/publish/publish/publish geplaatst. Als u wilt voorkomen dat publicatiemappen worden genest, geeft u een publicatiemap op die zich niet rechtstreeks onder de projectmap bevindt of sluit u de publicatiemap uit van het project. Als u een publicatiemap met de naam publishoutput wilt uitsluiten, voegt u het volgende element toe aan een PropertyGroup element in het .csproj-bestand :

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

    • .NET 7.0.200 SDK en hoger

      Als u de optie opgeeft bij het --output 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 --output optie is niet toegestaan omdat alle uitvoer van alle gemaakte 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 De optie Op oplossingsniveau --output is niet meer geldig voor build-gerelateerde opdrachten voor 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, geeft u een relatief pad op met behulp van de eigenschap msbuild PublishDir in plaats van de --output optie. Verzendt bijvoorbeeld dotnet publish -p:PublishDir=.\publish publicatie-uitvoer voor elk project naar een publish 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-id (RID), waarbij de opgegeven waarde wordt gecombineerd met de standaard-RID. Als u bijvoorbeeld op een win-x64 computer opgeeft --os linux , wordt de RID ingesteld op linux-x64. Als u deze optie gebruikt, gebruikt u de -r|--runtime optie 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 op te true geven of false, is de standaardwaarde true. In dat geval plaatst u de oplossing of het projectargument niet direct na --self-contained, omdat true of false wordt verwacht in die positie.

  • --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-catalogus voor 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 --self-contained u of --no-self-contained ook.

  • --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 slaat de omgevingscontrole over en schakelt terminallogboekregistratie in. off slaat de omgevingscontrole over en maakt gebruik van de standaardconsolelogger.

    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 het RuntimeIdentifier in op een platform dat draagbaar RuntimeIdentifier is op basis van een van uw computer. Dit gebeurt impliciet met eigenschappen waarvoor een RuntimeIdentifier, zoals SelfContained, PublishAot, PublishSelfContained, , en PublishSingleFilePublishReadyToRun. 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 zijnq[uiet], , , n[ormal]en diag[nostic]d[etailed]m[inimal]. De standaardwaarde is minimal. Zie LoggerVerbosity voor meer informatie.

  • --version-suffix <VERSION_SUFFIX>

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

Voorbeelden

  • Maak een frameworkafhankelijk binair binair platform voor het project in de huidige map:

    dotnet publish

    Vanaf .NET Core 3.0 SDK maakt dit voorbeeld ook een frameworkafhankelijk uitvoerbaar bestand voor het huidige platform.

  • Maak een zelfstandig uitvoerbaar bestand 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 uitvoerbaar bestand 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