dotnet publish

Artikel
01/08/2025

Dieser Artikel gilt für: ✔️ .NET Core 3.1 SDK und höhere Versionen

Name

dotnet publish – Veröffentlicht die Anwendung und deren Abhängigkeiten in einem Ordner für die Bereitstellung in einem Hostingsystem.

Zusammenfassung

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

Beschreibung

dotnet publish kompiliert die Anwendung, liest die in der Projektdatei angegebenen Abhängigkeiten und veröffentlicht den resultierenden Satz von Dateien in einem Verzeichnis. Die Ausgabe enthält die folgenden Ressourcen:

IL-Code (Intermediate Language) in einer Assembly mit einer DLL--Erweiterung.
Eine .deps.json Datei, die alle Abhängigkeiten des Projekts enthält.
Eine .runtimeconfig.json Datei, die die von der Anwendung erwartete freigegebene Laufzeit sowie andere Konfigurationsoptionen für die Laufzeit angibt (z. B. Garbage Collection-Typ).
Die Abhängigkeiten der Anwendung, die aus dem NuGet-Cache in den Ausgabeordner kopiert werden.

Die Ausgabe des dotnet publish Befehls ist bereit für die Bereitstellung in einem Hostingsystem (z. B. server, PC, Mac, Laptop) für die Ausführung. Es ist die einzige offiziell unterstützte Möglichkeit, die Anwendung für die Bereitstellung vorzubereiten. Je nachdem, welche Art von Bereitstellung das Projekt angibt, kann das Hostingsystem die freigegebene .NET-Laufzeit auf dem Hostsystem installiert haben. Weitere Informationen finden Sie unter Veröffentlichen von .NET-Apps mit der .NET CLI-.

Implizite Wiederherstellung

Sie müssen nicht dotnet restore ausführen, da sie implizit von allen Befehlen ausgeführt wird, die eine Wiederherstellung erfordern, z. B. dotnet new, dotnet build, dotnet run, dotnet test, dotnet publishund dotnet pack. Verwenden Sie zum Deaktivieren der impliziten Wiederherstellung die Option --no-restore.

Der Befehl dotnet restore ist in bestimmten Szenarien weiterhin nützlich, in denen die explizite Wiederherstellung sinnvoll ist, z. B. kontinuierlichen Integrationsbuilds in Azure DevOps Services oder in Buildsystemen, die explizit steuern müssen, wann die Wiederherstellung erfolgt.

Informationen zum Verwalten von NuGet-Feeds finden Sie in der dotnet restore Dokumentation.

MSBuild

Der befehl dotnet publish ruft MSBuild auf, wodurch das Publish Ziel aufgerufen wird. Wenn die IsPublishable Eigenschaft für ein bestimmtes Projekt auf false festgelegt ist, kann das Publish Ziel nicht aufgerufen werden, und der Befehl dotnet publish führt nur die implizite dotnet restore für das Projekt aus.

Alle parameter, die an dotnet publish übergeben werden, werden an MSBuild übergeben. Die parameter -c und -o werden den Configuration- bzw. PublishDir eigenschaften von MSBuild zugeordnet.

Der befehl dotnet publish akzeptiert MSBuild-Optionen, z. B. -p zum Festlegen von Eigenschaften und -l zum Definieren eines Loggers. Sie können beispielsweise eine MSBuild-Eigenschaft mithilfe des Formats festlegen: -p:<NAME>=<VALUE>.

PUBXML-Dateien

Sie können auch Veröffentlichungseigenschaften festlegen, indem Sie auf eine PUBXML--Datei verweisen. Zum Beispiel:

dotnet publish -p:PublishProfile=FolderProfile

Im vorherigen Beispiel wird die FolderProfile.pubxml-Datei verwendet, die im Ordner <project_folder>/Properties/PublishProfiles gefunden wird. Wenn Sie beim Festlegen der PublishProfile-Eigenschaft einen Pfad und eine Dateierweiterung angeben, werden sie ignoriert. MSBuild sucht standardmäßig im Ordner Properties/PublishProfiles ordner und geht davon aus, dass die pubxml Dateierweiterung. Wenn Sie den Pfad und dateinamen einschließlich der Erweiterung angeben möchten, legen Sie die eigenschaft PublishProfileFullPath anstelle der eigenschaft PublishProfile fest.

In der datei .pubxml:

PublishUrl wird von Visual Studio verwendet, um das Veröffentlichungsziel zu kennzeichnen.
PublishDir wird von der CLI verwendet, um das Veröffentlichungsziel zu kennzeichnen.

Wenn das Szenario an allen Stellen funktionieren soll, können Sie beide Eigenschaften in der PUBXML--Datei initialisieren. Wenn das GitHub-Problem dotnet/sdk#20931 behoben ist, muss nur eine dieser Eigenschaften festgelegt werden.

Einige Eigenschaften in der PUBXML--Datei werden nur von Visual Studio berücksichtigt und wirken sich nicht auf dotnet publishaus. Wir arbeiten daran, die CLI stärker auf das Verhalten von Visual Studio auszurichten. Einige Eigenschaften werden jedoch nie von der CLI verwendet. Die CLI und Visual Studio führen sowohl den Verpackungsaspekt der Veröffentlichung als auch dotnet/sdk#29817 Pläne aus, unterstützung für weitere Eigenschaften hinzuzufügen, die sich darauf beziehen. Die CLI macht jedoch nicht den Automatisierungsaspekt der Bereitstellung von Veröffentlichungen und Eigenschaften, die nicht unterstützt werden. Die wichtigsten .pubxml- Eigenschaften, die von dotnet publish nicht unterstützt werden, sind die folgenden Eigenschaften, die sich auf den Build auswirken:

LastUsedBuildConfiguration
Configuration
Platform
LastUsedPlatform
TargetFramework
TargetFrameworks
RuntimeIdentifier
RuntimeIdentifiers

MSBuild-Eigenschaften

Die folgenden MSBuild-Eigenschaften ändern die Ausgabe von dotnet publish.

PublishReadyToRun

Kompiliert Anwendungsassemblys als ReadyToRun (R2R)-Format. R2R ist eine Form der AOT-Kompilierung (Ahead-of-Time). Weitere Informationen finden Sie unter ReadyToRun-Bilder.

Um Warnungen zu fehlenden Abhängigkeiten anzuzeigen, die Laufzeitfehler verursachen könnten, verwenden Sie PublishReadyToRunShowWarnings=true.

Es wird empfohlen, PublishReadyToRun in einem Veröffentlichungsprofil und nicht in der Befehlszeile anzugeben.
PublishSingleFile

Verpackt die App in eine plattformspezifische ausführbare Datei. Weitere Informationen zur Veröffentlichung mit einer Datei finden Sie im Designdokument für ein dateiübergreifendes Bundler.

Es wird empfohlen, diese Option in der Projektdatei anstelle der Befehlszeile anzugeben.
PublishTrimmed

Kürzet nicht verwendete Bibliotheken, um die Bereitstellungsgröße einer App beim Veröffentlichen einer eigenständigen ausführbaren Datei zu verringern. Weitere Informationen finden Sie unter Kürzen eigenständiger Bereitstellungen und ausführbarer Dateien. Verfügbar seit .NET 6 SDK.

Es wird empfohlen, diese Option in der Projektdatei anstelle der Befehlszeile anzugeben.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Workloadmanifestdownloads

Wenn Sie diesen Befehl ausführen, wird ein asynchroner Hintergrunddownload von Werbemanifesten für Workloads initiiert. Wenn der Download nach Abschluss dieses Befehls noch ausgeführt wird, wird der Download beendet. Weitere Informationen finden Sie unter Advertising-Manifeste.

Argumente

PROJECT|SOLUTION

Das zu veröffentlichende Projekt oder die Projektmappe.
- PROJECT ist der Pfad und Dateiname einer C#-, F#- oder Visual Basic-Projektdatei oder der Pfad zu einem Verzeichnis, das eine C#-, F#- oder Visual Basic-Projektdatei enthält. Wenn das Verzeichnis nicht angegeben ist, wird es standardmäßig auf das aktuelle Verzeichnis festgelegt.
- SOLUTION ist der Pfad und Dateiname einer Lösungsdatei (.sln Erweiterung) oder der Pfad zu einem Verzeichnis, das eine Lösungsdatei enthält. Wenn das Verzeichnis nicht angegeben ist, wird es standardmäßig auf das aktuelle Verzeichnis festgelegt.

Optionen

-a|--arch <ARCHITECTURE>

Gibt die Zielarchitektur an. Dies ist eine Abkürzungssyntax zum Festlegen der Runtime Identifier (RID), wobei der angegebene Wert mit dem Standardmäßigen RID kombiniert wird. Geben Sie z. B. auf einem win-x64 Computer an, --arch x86 die RID-Eigenschaft auf win-x86festlegt. Wenn Sie diese Option verwenden, verwenden Sie nicht die Option -r|--runtime. Verfügbar seit .NET 6 Preview 7.

--artifacts-path <ARTIFACTS_DIR>

Alle Buildausgabedateien des ausgeführten Befehls werden in Unterordnern unter dem angegebenen Pfad, getrennt durch Das Projekt, verschoben. Weitere Informationen finden Sie unter Artifacts Output Layout. Verfügbar seit .NET 8 SDK.

-c|--configuration <CONFIGURATION>

Definiert die Buildkonfiguration. Wenn Sie mit dem .NET 8 SDK oder einer höheren Version entwickeln, verwendet der Befehl standardmäßig die Release-Konfiguration für Projekte, deren TargetFramework auf net8.0 oder eine höhere Version festgelegt ist. Die Standardbuildkonfiguration wird für frühere Versionen des SDK und für frühere Zielframeworks Debug. Sie können die Standardeinstellung in den Projekteinstellungen oder mithilfe dieser Option außer Kraft setzen. Weitere Informationen finden Sie unter "dotnet publish" verwendet release configuration und "dotnet pack" verwendet release configuration.

--disable-build-servers

Erzwingt den Befehl, alle persistenten Buildserver zu ignorieren. Diese Option bietet eine konsistente Möglichkeit, die gesamte Verwendung von Buildzwischenspeicherung zu deaktivieren, wodurch ein Build von Grund auf neu erzwungen wird. Ein Build, der nicht auf Caches angewiesen ist, ist nützlich, wenn die Caches aus irgendeinem Grund beschädigt oder falsch sind. Verfügbar seit .NET 7 SDK.

-f|--framework <FRAMEWORK>

Veröffentlicht die Anwendung für das angegebene Zielframework. Sie müssen das Zielframework in der Projektdatei angeben.
--force

Erzwingt, dass alle Abhängigkeiten aufgelöst werden, auch wenn die letzte Wiederherstellung erfolgreich war. Die Angabe dieses Flags entspricht dem Löschen der project.assets.json Datei.

-?|-h|--help

Gibt eine Beschreibung der Verwendung des Befehls aus.

--interactive

Ermöglicht es dem Befehl, die Benutzereingabe oder -aktion zu beenden und zu warten. Um beispielsweise die Authentifizierung abzuschließen. Verfügbar seit .NET Core 3.0 SDK.

--manifest <PATH_TO_MANIFEST_FILE>

Gibt ein oder mehrere Zielmanifeste an, die verwendet werden sollen, um den Satz von Paketen zu kürzen, die mit der App veröffentlicht wurden. Die Manifestdatei ist Teil der Ausgabe des dotnet store Befehls. Um mehrere Manifeste anzugeben, fügen Sie für jedes Manifest eine --manifest Option hinzu.
--no-build

Erstellt das Projekt nicht vor der Veröffentlichung. Außerdem wird das --no-restore Flag implizit festgelegt.
--no-dependencies

Ignoriert Projekt-zu-Projekt-Verweise und stellt nur das Stammprojekt wieder her.
--nologo

Zeigt das Startbanner oder die Copyrightnachricht nicht an.
--no-restore

Führt beim Ausführen des Befehls keine implizite Wiederherstellung aus.
-o|--output <OUTPUT_DIRECTORY>

Gibt den Pfad für das Ausgabeverzeichnis an.

Wenn nicht angegeben, wird standardmäßig [project_file_folder]/bin/[configuration]/[framework]/publish/ für eine frameworkabhängige ausführbare Datei und plattformübergreifende Binärdateien verwendet. Standardmäßig [project_file_folder]/bin/[configuration]/[framework]/[runtime]/publish/ für eine eigenständige ausführbare Datei.

Wenn sich der Ausgabeordner in einem Webprojekt im Projektordner befindet, führen aufeinander folgende dotnet publish Befehle zu geschachtelten Ausgabeordnern. Wenn der Projektordner beispielsweise myproject-ist und der Ausgabeordner für die Veröffentlichung myproject/publishist und Sie dotnet publish zweimal ausführen, platziert die zweite Ausführung Inhaltsdateien wie .config und .json Dateien in myproject/publish/publish. Um das Verschachteln von Veröffentlichungsordnern zu vermeiden, geben Sie einen Veröffentlichungsordner an, der nicht direkt unter dem Projektordner , oder schließen Sie den Veröffentlichungsordner aus dem Projekt aus. Um einen Veröffentlichungsordner mit dem Namen publishoutputauszuschließen, fügen Sie das folgende Element zu einem PropertyGroup Element in der CSPROJ- Datei hinzu:
```
<DefaultItemExcludes>$(DefaultItemExcludes);publishoutput**</DefaultItemExcludes>
```
- .NET 7.0.200 SDK und höher
  
  Wenn Sie beim Ausführen dieses Befehls auf einer Lösung die Option --output angeben, gibt die CLI aufgrund der unklaren Semantik des Ausgabepfads eine Warnung (ein Fehler in 7.0.200) aus. Die option --output ist unzulässig, da alle Ausgaben aller erstellten Projekte in das angegebene Verzeichnis kopiert werden, das nicht mit multizielorientierten Projekten kompatibel ist, sowie Projekte mit unterschiedlichen Versionen von direkten und transitiven Abhängigkeiten. Weitere Informationen finden Sie unter Option auf Lösungsebene --output nicht mehr gültig für buildbezogene Befehle.
- .NET Core 3.x SDK und höher
  
  Wenn Sie beim Veröffentlichen eines Projekts einen relativen Pfad angeben, ist das generierte Ausgabeverzeichnis relativ zum aktuellen Arbeitsverzeichnis und nicht zum Speicherort der Projektdatei.
  
  Wenn Sie beim Veröffentlichen einer Lösung einen relativen Pfad angeben, werden alle Ausgaben für alle Projekte relativ zum aktuellen Arbeitsverzeichnis in den angegebenen Ordner verschoben. Um die Veröffentlichung zu separaten Ordnern für jedes Projekt zu erstellen, geben Sie einen relativen Pfad an, indem Sie die Eigenschaft msbuild PublishDir anstelle der Option --output verwenden. Beispielsweise sendet dotnet publish -p:PublishDir=.\publish die Veröffentlichungsausgabe für jedes Projekt an einen publish Ordner unter dem Ordner, der die Projektdatei enthält.
- .NET Core 2.x SDK
  
  Wenn Sie beim Veröffentlichen eines Projekts einen relativen Pfad angeben, ist das generierte Ausgabeverzeichnis relativ zum Speicherort der Projektdatei und nicht zum aktuellen Arbeitsverzeichnis.
  
  Wenn Sie beim Veröffentlichen einer Projektmappe einen relativen Pfad angeben, wird die Ausgabe jedes Projekts in einen separaten Ordner relativ zum Speicherort der Projektdatei verschoben. Wenn Sie beim Veröffentlichen einer Lösung einen absoluten Pfad angeben, werden alle Veröffentlichungsausgaben für alle Projekte in den angegebenen Ordner verschoben.

--os <OS>

Gibt das Zielbetriebssystem (Betriebssystem) an. Dies ist eine Abkürzungssyntax zum Festlegen der Runtime Identifier (RID), wobei der angegebene Wert mit dem Standardmäßigen RID kombiniert wird. Geben Sie z. B. auf einem win-x64 Computer an, --os linux die RID-Eigenschaft auf linux-x64festlegt. Wenn Sie diese Option verwenden, verwenden Sie nicht die Option -r|--runtime. Verfügbar seit .NET 6.

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

Veröffentlicht die .NET-Laufzeit mit Ihrer Anwendung, damit die Laufzeit nicht auf dem Zielcomputer installiert werden muss. Der Standardwert ist true, wenn ein Laufzeitbezeichner angegeben ist und das Projekt ein ausführbares Projekt ist (kein Bibliotheksprojekt). Weitere Informationen finden Sie unter .NET Application Publishing und Publish .NET apps with the .NET CLI.

Wenn diese Option ohne Angabe von true oder falseverwendet wird, ist die Standardeinstellung true. Platzieren Sie in diesem Fall das Projekt- oder Projektargument nicht unmittelbar nach --self-contained, da true oder false an dieser Position erwartet wird.
--no-self-contained

Entspricht --self-contained false.
--source <SOURCE>

Der URI der NuGet-Paketquelle, die während des Wiederherstellungsvorgangs verwendet werden soll.
-r|--runtime <RUNTIME_IDENTIFIER>

Veröffentlicht die Anwendung für eine bestimmte Laufzeit. Eine Liste der Runtime Identifiers (RIDs) finden Sie im RID-Katalog. Weitere Informationen finden Sie unter .NET Application Publishing und Publish .NET apps with the .NET CLI. Wenn Sie diese Option verwenden, verwenden Sie auch --self-contained oder --no-self-contained.

--tl:[auto|on|off]

Gibt an, ob der Terminalprotokollierer für die Buildausgabe verwendet werden soll. Der Standardwert ist auto, wodurch zuerst die Umgebung überprüft wird, bevor die Terminalprotokollierung aktiviert wird. Die Umgebung überprüft, ob das Terminal moderne Ausgabefeatures verwenden kann und keine umgeleitete Standardausgabe verwendet, bevor der neue Logger aktiviert wird. on überspringt die Umgebungsprüfung und aktiviert die Terminalprotokollierung. off überspringt die Umgebungsprüfung und verwendet den Standardkonsolenprotokollierer.

Der Terminalprotokollierer zeigt Ihnen die Wiederherstellungsphase gefolgt von der Buildphase. In jeder Phase werden die derzeit bauende Projekte am Unteren Ende des Terminals angezeigt. Jedes Projekt, das erstellt wird, gibt sowohl das msBuild-Ziel aus, das derzeit erstellt wird, als auch die für dieses Ziel aufgewendete Zeit. Sie können diese Informationen durchsuchen, um mehr über den Build zu erfahren. Wenn das Erstellen eines Projekts abgeschlossen ist, wird ein einzelner Abschnitt "Build abgeschlossen" geschrieben, der folgendes erfasst:
- Der Name des erstellten Projekts.
- Das Zielframework (wenn multi-targeted).
- Der Status dieses Builds.
- Die primäre Ausgabe dieses Builds (die mit Hyperlink versehen ist).
- Jede für dieses Projekt generierte Diagnose.
Diese Option ist ab .NET 8 verfügbar.

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

Legt die RuntimeIdentifier auf eine plattform portable RuntimeIdentifier basierend auf dem gerät fest. Dies geschieht implizit mit Eigenschaften, die eine RuntimeIdentifiererfordern, z. B. SelfContained, PublishAot, PublishSelfContained, PublishSingleFileund PublishReadyToRun. Wenn die Eigenschaft auf "false" festgelegt ist, tritt diese implizite Auflösung nicht mehr auf.

-v|--verbosity <LEVEL>

Legt die Ausführlichkeitsebene des Befehls fest. Zulässige Werte sind q[uiet], m[inimal], n[ormal], d[etailed]und diag[nostic]. Der Standardwert ist minimal. Weitere Informationen finden Sie unter LoggerVerbosity.

--version-suffix <VERSION_SUFFIX>

Definiert das Versionssuffix, um das Sternchen (*) im Versionsfeld der Projektdatei zu ersetzen.

Beispiele

Erstellen Sie eine frameworkabhängigen plattformübergreifenden binären für das Projekt im aktuellen Verzeichnis:
```
dotnet publish
```
Ab .NET Core 3.0 SDK erstellt dieses Beispiel auch eine frameworkabhängige ausführbare für die aktuelle Plattform.
Erstellen Sie eine eigenständige ausführbare für das Projekt im aktuellen Verzeichnis für eine bestimmte Laufzeit:
```
dotnet publish --runtime osx-x64
```
Das RID muss sich in der Projektdatei befinden.
Erstellen Sie eine frameworkabhängige ausführbare für das Projekt im aktuellen Verzeichnis für eine bestimmte Plattform:
```
dotnet publish --runtime osx-x64 --self-contained false
```
Das RID muss sich in der Projektdatei befinden. Dieses Beispiel gilt für .NET Core 3.0 SDK und höhere Versionen.
Veröffentlichen Sie das Projekt im aktuellen Verzeichnis für ein bestimmtes Laufzeit- und Zielframework:
```
dotnet publish --framework net8.0 --runtime osx-x64
```
Veröffentlichen Sie die angegebene Projektdatei:
```
dotnet publish ~/projects/app1/app1.csproj
```
Veröffentlichen Sie die aktuelle Anwendung, stellen Sie jedoch keine Projekt-zu-Projekt-Verweise (P2P) wieder her, sondern nur das Stammprojekt während des Wiederherstellungsvorgangs:
```
dotnet publish --no-dependencies
```

Freigeben über