dotnet publish

  • Artikel

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

Name

dotnet publish veröffentlicht die Anwendung und ihre Abhängigkeiten in einem Ordner für die Bereitstellung auf einem Hostsystem.

Übersicht

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 ihre Abhängigkeiten, die in der Projektdatei angegeben sind, und veröffentlicht die resultierenden Dateien in einem Verzeichnis. Die Ausgabe umfasst die folgenden Objekte:

  • Intermediate Language-Code (IL) in einer Assembly mit einer DLL-Erweiterung.
  • Die Datei .deps.json, die alle Abhängigkeiten des Projekts enthält
  • Die Datei .runtimeconfig.json, die die Shared Runtime, die von der Anwendung erwartet wird, sowie andere Konfigurationsoptionen für die Runtime festlegt (z. B. die Art der Garbage Collection).
  • Die Abhängigkeiten der Anwendung, die aus dem NuGet-Cache in den Ausgabeordner kopiert werden.

Die Ausgabe des Befehls dotnet publish steht für die Bereitstellung zur Ausführung auf einem Hostsystem bereit (z.B. ein Server, Computer, Mac oder Laptop). Es ist die einzige offiziell unterstützte Methode zum Vorbereiten der Anwendung für die Bereitstellung. Je nach Art der Bereitstellung, die im Projekt angegeben ist, ist die Shared Runtime von .NET im Hostsystem installiert oder nicht. Weitere Informationen finden Sie unter Veröffentlichen von .NET-Apps mit der .NET-CLI.

Implizite Wiederherstellung

Sie müssen dotnet restore nicht ausführen, da der Befehl implizit von allen Befehlen ausgeführt wird, die eine Wiederherstellung erfordern. Zu diesen zählen z. B. dotnet new, dotnet build, dotnet run, dotnet test, dotnet publish und dotnet pack. Verwenden Sie die Option --no-restore, um die implizite Wiederherstellung zu deaktivieren.

In bestimmten Fällen eignet sich der dotnet restore-Befehl dennoch. Dies ist etwa bei Szenarios der Fall, in denen die explizite Wiederherstellung sinnvoll ist. Beispiele hierfür sind Continuous Integration-Builds in Azure DevOps Services oder Buildsysteme, die den Zeitpunkt für die Wiederherstellung explizit steuern müssen.

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

MSBuild

Der Befehl dotnet publish ruft MSBuild auf, welches das Publish-Ziel aufruft. 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 impliziten dotnet restore-Befehle für das Projekt aus.

Alle Parameter, die an dotnet publish übergeben werden, werden an MSBuild übergeben. Die Parameter -c und -o verweisen auf die MSBuild-Eigenschaften Configuration bzw. PublishDir.

Der dotnet publish-Befehl akzeptiert MSBuild-Optionen, z. B. -p zum Festlegen von Eigenschaften oder -l zum Definieren eines Protokolls. Beispielsweise können Sie eine MSBuild-Eigenschaft mit dem folgenden Format 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 Datei FolderProfile.pubxml verwendet, die sich im Ordner <project_folder>/Properties/PublishProfiles befindet. Wenn Sie beim Festlegen der PublishProfile-Eigenschaft einen Pfad und eine Dateierweiterung angeben, werden diese ignoriert. MSBuild sucht standardmäßig im Ordner Properties/PublishProfiles und übernimmt die PUBXML-Dateierweiterung. Um den Pfad und den Dateinamen einschließlich der Erweiterung anzugeben, legen Sie die PublishProfileFullPath-Eigenschaft anstelle der PublishProfile-Eigenschaft fest.

In der PUBXML-Datei:

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

Wenn das Szenario an allen Orten funktioniert, können Sie beide Eigenschaften mit demselben Wert in der PUBXML-Datei initialisieren. Wenn das GitHub-Problem dotnet/sdk#20931 behoben wurde, 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 publish aus. 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 übernehmen sowohl den Verpackungsaspekt der Veröffentlichung als auch dotnet/sdk#29817-Pläne, um Unterstützung für weitere Eigenschaften hinzuzufügen, die sich darauf beziehen. Aber die CLI übernimmt nicht den Aspekt der Automatisierung der Bereitstellung und die damit verbundenen Eigenschaften werden nicht unterstützt. 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 im R2R-Format (ReadyToRun). R2R ist eine Form der AOT-Kompilierung (Ahead-Of-Time). Weitere Informationen finden Sie unter ReadyToRun-Images.

    Verwenden Sie PublishReadyToRunShowWarnings=true, um Warnungen zu fehlenden Abhängigkeiten anzuzeigen, die zu Runtimefehlern führen könnten.

    Es wird empfohlen, PublishReadyToRun nicht über die Befehlszeile, sondern in einem Veröffentlichungsprofil anzugeben.

  • PublishSingleFile

    Packt die App in einer plattformspezifischen ausführbaren Einzeldatei. Weitere Informationen zum Veröffentlichen einzelner Dateien finden Sie im Einzeldatei-Bundler-Entwurfsdokument.

    Es wird empfohlen, diese Option nicht über die Befehlszeile, sondern in der Projektdatei anzugeben.

  • PublishTrimmed

    Kürzt nicht verwendete Bibliotheken, um die Bereitstellungsgröße einer App zu verringern, wenn diese als selbstextrahierende ausführbare Datei veröffentlicht wird. Weitere Informationen finden Sie unter Kürzen eigenständiger Bereitstellungen und ausführbarer Dateien. Verfügbar ab .NET 6 SDK.

    Es wird empfohlen, diese Option nicht über die Befehlszeile, sondern in der Projektdatei anzugeben.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Workload manifest downloads

Wenn Sie diesen Befehl ausführen, wird im Hintergrund ein asynchroner Download initiiert, der Ankündigungsmanifeste für Workloads herunterlädt. Wenn der Download noch ausgeführt wird, wenn der Befehl abgeschlossen ist, wird der Download angehalten. Weitere Informationen finden Sie unter Ankündigungsmanifeste.

Argumente

  • PROJECT|SOLUTION

    Das Projekt bzw. die Projektmappe, die veröffentlicht werden soll.

    • PROJECT entspricht dem Pfad und Dateinamen einer C#-, F#- oder Visual Basic-Projektdatei oder dem Pfad zu einem Verzeichnis, das eine C#-, F#- oder Visual Basic-Projektdatei enthält. Wenn das Verzeichnis nicht angegeben wird, wird standardmäßig das aktuelle Verzeichnis verwendet.

    • SOLUTION ist der Pfad und Dateiname einer Projektmappendatei (mit der Erweiterung .sln), oder der Pfad zu einem Verzeichnis, das eine Projektmappendatei enthält. Wenn das Verzeichnis nicht angegeben wird, wird standardmäßig das aktuelle Verzeichnis verwendet.

Optionen

  • -a|--arch <ARCHITECTURE>

    Legt die Zielarchitektur fest. Dies ist eine Kurzsyntax zum Setzen des Runtimebezeichners (RID), wobei der angegebene Wert mit dem Standard-RID kombiniert wird. Auf einem win-x64 Rechner wird beispielsweise durch die Angabe von --arch x86 der RID auf win-x86 gesetzt. Wenn Sie diese Option verwenden, dürfen Sie Option -r|--runtime nicht verwenden. 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 ab dem .NET 8 SDK.

  • -c|--configuration <CONFIGURATION>

    Legt die Buildkonfiguration fest. 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 ist Debug für frühere Versionen des SDK und für frühere Zielframeworks vorgesehen. Sie können die Standardeinstellung in den Projekteinstellungen oder mithilfe dieser Option außer Kraft setzen. Weitere Informationen finden Sie unter "dotnet publish" verwendet die Releasekonfiguration und "dotnet pack" verwendet die Release-Konfiguration.

  • --disable-build-servers

    Erzwingt, dass der Befehl alle persistenten Buildserver ignoriert. Diese Option bietet eine konsistente Möglichkeit, die gesamte Verwendung von Buildcaches zu deaktivieren, wodurch die Neuerstellung eines Build von Grund auf erzwungen wird. Ein Build, der sich nicht auf Caches stützt, ist nützlich, wenn die Caches aus irgendeinem Grund beschädigt oder fehlerhaft sein können. Verfügbar ab dem .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 das Auflösen aller Abhängigkeiten, auch wenn die letzte Wiederherstellung erfolgreich war. Dieses Flag anzugeben, entspricht dem Löschen der Datei project.assets.json.

  • -?|-h|--help

    Gibt eine Beschreibung zur Verwendung des Befehls aus.

  • --interactive

    Ermöglicht dem Befehl, anzuhalten und auf Benutzereingaben oder Aktionen zu warten. Beispielsweise, um die Authentifizierung abzuschließen. Verfügbar seit .NET Core 3.0 SDK.

  • --manifest <PATH_TO_MANIFEST_FILE>

    Gibt mindestens ein Zielmanifest an, das verwendet wird, um die Menge an mit der App veröffentlichten Paketen zu senken. Die Manifestdatei ist Teil der Ausgabe des dotnet store-Befehls. Um mehrere Manifeste anzugeben, fügen Sie die --manifest-Option für jedes Manifest hinzu.

  • --no-build

    Erstellt das Projekt nicht vor der Veröffentlichung. Zudem wird das Flag --no-restore implizit festgelegt.

  • --no-dependencies

    Ignoriert Verweise zwischen Projekten und stellt nur das zum Erstellen angegebene Stammprojekt wieder her.

  • --nologo

    Unterdrückt die Anzeige von Startbanner und Copyrightmeldung.

  • --no-restore

    Führt keine implizite Wiederherstellung aus, wenn der Befehl ausgeführt wird.

  • -o|--output <OUTPUT_DIRECTORY>

    Gibt den Pfad für das Ausgabeverzeichnis an.

    Wenn diese Option nicht angegeben wird, wird für frameworkabhängige ausführbare Dateien und plattformübergreifende Binärdateien standardmäßig [Projektdateiordner]/bin/[Konfiguration]/[Framework]/publish/ verwendet. Für eigenständige ausführbare Dateien wird standardmäßig [Projektdateiordner]./bin/[Konfiguration]/[Framework]/[Runtime]/publish/ verwendet.

    In einem Webprojekt führen aufeinanderfolgende dotnet publish-Befehle zu geschachtelten Ausgabeordnern, wenn sich der Ausgabeordner im Projektordner befindet. Wenn der Projektordner beispielsweise MeinProjekt lautet und als Ausgabeordner MeinProjekt/publish festgelegt ist, werden bei zweimaliger Ausführung von dotnet publish die Inhaltsdateien (beispielsweise die CONFIG- und JSON-Dateien) der zweiten Ausführung in MeinProjekt/publish/publish platziert. Um eine Schachtelung der Veröffentlichungsordner zu vermeiden, geben Sie einen Ordner für die Veröffentlichung an, der sich nicht direkt unter dem Projektordner befindet. Alternativ können Sie den Veröffentlichungsordner aus dem Projekt ausschließen. Um einen Veröffentlichungsordner namens publishoutput auszuschließen, fügen Sie das folgende Element 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 in einer Projektmappe die --output-Option angeben, gibt die CLI aufgrund der unklaren Semantik des Ausgabepfads eine Warnung (einen Fehler in 7.0.200) aus. Die --output-Option ist unzulässig, da alle Ausgaben aller erstellten Projekte in das angegebene Verzeichnis kopiert werden, das nicht mit Projekten mit mehreren Zielen kompatibel ist, sowie Projekten mit unterschiedlichen Versionen von direkten und transitiven Abhängigkeiten. Weitere Informationen finden Sie unter Option --output auf Projektmappenebene ist für buildbezogene Befehle nicht mehr gültig.

    • .NET Core 3. x SDK und höher

      Wenn beim Veröffentlichen eines Projekts ein relativer Pfad angegeben wird, ist das generierte Ausgabeverzeichnis relativ zum aktuellen Arbeitsverzeichnis statt zum Speicherort der Projektdatei.

      Wenn beim Veröffentlichen einer Projektmappe ein relativer Pfad angegeben wird, werden alle Ausgaben für sämtliche Projekte im angegebenen Ordner relativ zum aktuellen Arbeitsverzeichnis gespeichert. Um die Veröffentlichungsausgabe in eigenen Ordnern für jedes Projekt zu speichern, geben Sie einen relativen Pfad an, indem Sie die MSBuild-PublishDir-Eigenschaft anstelle der --output-Option verwenden. Beispielsweise wird mit dotnet publish -p:PublishDir=.\publish die Veröffentlichungsausgabe für jedes Projekt an den Ordner publish unter dem Ordner gesendet, der die Projektdatei enthält.

    • .NET Core 2.x SDK

      Wenn beim Veröffentlichen eines Projekts ein relativer Pfad angegeben wird, ist das generierte Ausgabeverzeichnis relativ zum Speicherort der Projektdatei statt zum aktuellen Arbeitsverzeichnis.

      Wenn beim Veröffentlichen einer Projektmappe ein relativer Pfad angegeben wird, wird die Ausgabe jedes Projekts in einem eigenen Ordner relativ zum Speicherort der Projektdatei gespeichert. Wenn beim Veröffentlichen einer Projektmappe ein absoluter Pfad angegeben wird, werden alle Veröffentlichungsausgaben für alle Projekte im angegebenen Ordner gespeichert.

  • --os <OS>

    Gibt das Zielbetriebssystem an. Dies ist eine Kompaktsyntax zum Festlegen des Runtimebezeichners (RID), wobei der angegebene Wert mit der Standard-RID kombiniert wird. Auf einem win-x64 Rechner wird beispielsweise durch die Angabe von --os linux der RID auf linux-x64 gesetzt. Wenn Sie diese Option verwenden, dürfen Sie Option -r|--runtime nicht verwenden. Verfügbar seit .NET 6.

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

    Veröffentlicht die .NET-Runtime mit Ihrer Anwendung, sodass die Runtime nicht auf dem Zielcomputer installiert werden muss. Der Standardwert ist true, wenn ein Laufzeitbezeichner angegeben wird und das Projekt ein ausführbares Projekt (kein Bibliotheksprojekt) ist. Weitere Informationen finden Sie unter Veröffentlichen von .NET-Anwendungen und Veröffentlichen von .NET-Apps mit der .NET-CLI.

    Wenn diese Option verwendet wird, ohne true oder false anzugeben, ist der Standardwert true. Fügen Sie in diesem Fall das Projektmappen- oder Projektargument nicht unmittelbar nach --self-contained ein, da an dieser Position true oder false erwartet wird.

  • --no-self-contained

    Entspricht --self-contained false.

  • --source <SOURCE>

    Der URI der NuGet-Paketquelle, die während des Wiederherstellungsvorgangs zu verwenden ist.

  • -r|--runtime <RUNTIME_IDENTIFIER>

    Veröffentlicht die Anwendung für eine bestimmte Laufzeit. Eine Liste der Runtime-IDs (RIDs) finden Sie unter RID-Katalog. Weitere Informationen finden Sie unter Veröffentlichen von .NET-Anwendungen und Veröffentlichen von .NET-Apps mit der .NET-CLI. Verwenden Sie bei dieser Option auch --self-contained oder --no-self-contained.

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

    Gibt an, ob die Terminalprotokollierung für die Buildausgabe verwendet werden soll. Der Standardwert ist auto, mit den zunächst die Umgebung überprüft wird, bevor die Terminalprotokollierung aktiviert wird. Die Umgebungsprüfung testet, ob das Terminal moderne Ausgabefeatures verwenden kann und keine umgeleitete Standardausgabe verwendet, bevor die neue Protokollierung aktiviert wird. on überspringt die Umgebungsprüfung und aktiviert die Terminalprotokollierung. off überspringt die Umgebungsprüfung und verwendet die Standardkonsolenprotokollierung.

    Die Terminalprotokollierung zeigt die Wiederherstellungsphase gefolgt von der Buildphase an. Während jeder Phase werden am unteren Rand des Terminals die derzeit erstellten Projekte angezeigt. Für jedes erstellte Projekt wird sowohl das MSBuild-Ziel für den Build als auch die Zeit ausgegeben, die für dieses Ziel aufgewendet wurde. Sie können diese Informationen durchsuchen, um mehr über den Build zu erfahren. Wenn die Erstellung eines Projekts abgeschlossen ist, wird ein einzelner Abschnitt „Build abgeschlossen“ geschrieben, in dem Folgendes erfasst wird:

    • Der Name des erstellten Projekts
    • Das Zielframework (bei mehreren Zielen)
    • Der Status dieses Builds
    • Die primäre Ausgabe dieses Builds (als Link)
    • Alle für dieses Projekt generierten Diagnoseinformationen

    Diese Option ist ab .NET 8 verfügbar.

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

    Legt den RuntimeIdentifier auf einen plattformübergreifenden RuntimeIdentifier fest, der auf dem Computer basiert. Dies erfolgt implizit bei Eigenschaften, die einen RuntimeIdentifiererfordern, z. B. SelfContained, PublishAot, PublishSelfContained, PublishSingleFile und PublishReadyToRun. Wenn die Eigenschaft auf FALSE festgelegt ist, tritt diese implizite Auflösung nicht mehr auf.

  • -v|--verbosity <LEVEL>

    Legt den Ausführlichkeitsgrad für den Befehl 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 zum Ersetzen des Sternchens (*) im Versionsfeld der Projektdatei.

Beispiele

  • Erstellen Sie eine frameworkabhängige plattformübergreifende Binärdatei für das Projekt im aktuellen Verzeichnis:

    dotnet publish

    Ab dem .NET Core SDK 3.0 wird mit diesem Beispielbefehl eine frameworkabhängige ausführbare Datei für die aktuelle Plattform erstellt.

  • Erstellen Sie für das Projekt im aktuellen Verzeichnis eine eigenständige ausführbare Datei für eine spezifische Runtime:

    dotnet publish --runtime osx-x64

    Die RID muss in der Projektdatei enthalten sein.

  • Erstellen Sie für das Projekt im aktuellen Verzeichnis eine frameworkabhängige ausführbare Datei für eine spezifische Plattform:

    dotnet publish --runtime osx-x64 --self-contained false

    Die RID muss in der Projektdatei enthalten sein. Dieses Beispiel gilt für .NET Core 3.0 SDK und höher.

  • Veröffentlichen Sie das Projekt im aktuellen Verzeichnis für eine spezifische Runtime und ein spezifisches 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, aber fügen Sie während der Wiederherstellung keine Projekt-zu-Projekt-Verweise hinzu, sondern nur das Stammprojekt:

    dotnet publish --no-dependencies

Siehe auch