Übersicht über die .NET-Anwendungsveröffentlichung

In diesem Artikel werden die verschiedenen Methoden zum Veröffentlichen einer .NET-Anwendung erläutert. Es umfasst Veröffentlichungsmodi, wie ausführbare Dateien und plattformübergreifende Binärdateien erstellt werden, und die Auswirkungen jedes Ansatzes auf Bereitstellungs- und Laufzeitumgebungen. Sie können .NET-Anwendungen entweder über die .NET CLI oder Visual Studio veröffentlichen.

Was ist die Veröffentlichung?

Das Veröffentlichen einer .NET-App bedeutet das Kompilieren von Quellcode zum Erstellen einer ausführbaren oder binären Datei zusammen mit den Abhängigkeiten und zugehörigen Dateien zur Verteilung. Nach der Veröffentlichung stellen Sie die App auf einem Server, einer Verteilungsplattform, einem Container oder einer Cloudumgebung bereit. Der Veröffentlichungsprozess bereitet eine App für die Bereitstellung und Verwendung außerhalb einer Entwicklungsumgebung vor.

Veröffentlichungsmodi

Es gibt zwei haupt möglichkeiten, eine App zu veröffentlichen. Einige Faktoren, die diese Entscheidung beeinflussen, umfassen, ob die Bereitstellungsumgebung die entsprechende .NET-Runtime installiert hat und ob Sie bestimmte Kompilierungsfeatures benötigen, die die Laufzeit mit Ihrer App bündeln müssen. Die beiden Veröffentlichungsmodi sind:

• Eigenständiges Veröffentlichen
  Dieser Modus erzeugt einen Veröffentlichungsordner, der eine plattformspezifische ausführbare Datei enthält, die zum Starten der App verwendet wird, eine kompilierte Binärdatei mit App-Code, alle App-Abhängigkeiten und die .NET-Laufzeit, die zum Ausführen der App erforderlich ist. Die Umgebung, in der die App ausgeführt wird, muss die .NET-Laufzeit nicht vorinstalliert sein.

• Framework-abhängig veröffentlichen
  Dieser Modus erzeugt einen Veröffentlichungsordner, der eine plattformspezifische ausführbare Datei enthält, die zum Starten der App, eine kompilierte Binärdatei mit App-Code und alle App-Abhängigkeiten verwendet wird. Die Umgebung, in der die App ausgeführt wird, muss über eine Version der .NET-Laufzeit verfügen, die von der App verwendet werden kann. Eine optionale plattformspezifische ausführbare Datei kann erstellt werden.

Grundlagen zum Veröffentlichen

Die <TargetFramework> Einstellung der Projektdatei gibt das Standardzielframework an, wenn Sie Ihre App veröffentlichen. Sie können das Zielframework in ein beliebiges gültiges Target Framework Moniker (TFM) ändern. Wenn Ihr Projekt beispielsweise verwendet <TargetFramework>net9.0</TargetFramework>wird, wird eine Binärdatei erstellt, die auf .NET 9 ausgerichtet ist.

Wenn Sie mehrere Frameworks als Ziel festlegen möchten, können Sie die <TargetFrameworks> Einstellung auf mehrere TFM-Werte festlegen, getrennt durch ein Semikolon. Wenn Sie Ihre App erstellen, wird Ihre App für jedes Zielframework erstellt, das von Ihrem Projekt definiert wird. Wenn Sie Ihre App veröffentlichen, müssen Sie jedoch das Zielframework angeben:

dotnet publish -c Release -f net9.0

Portable Binärdateien

Wenn Sie eine .NET-App veröffentlichen, können Sie auf eine bestimmte Plattform abzielen oder eine portable Binärdatei erstellen. Selbst beim Erstellen einer tragbaren Binärdatei veröffentlicht .NET standardmäßig eine plattformspezifische ausführbare Datei zusammen mit der portablen DLL, es sei denn, Sie deaktivieren dieses Verhalten explizit.

Die plattformspezifische ausführbare Datei wird aufgrund der UseAppHost Eigenschaft erstellt, die standardmäßig auf true. Wenn Sie nur die portable DLL ohne die plattformspezifische ausführbare Datei veröffentlichen möchten, legen Sie sie entweder in der Befehlszeile (-p:UseAppHost=false) oder als Projekteigenschaft fest UseAppHostfalse.

Der Vorteil der Ausrichtung auf eine bestimmte Plattform besteht darin, dass sie systemeigene Abhängigkeiten verarbeiten kann, die Ihre App möglicherweise benötigt, um die Kompatibilität mit den spezifischen Anforderungen der Zielplattform sicherzustellen.

Systemeigene Abhängigkeiten

Wenn Ihre App über systemeigene Abhängigkeiten verfügt, wird sie möglicherweise nicht auf einem anderen Betriebssystem ausgeführt, wenn sie als portable Binärdatei veröffentlicht wird. Beispielsweise werden Apps, die von der Windows-API abhängen, nicht nativ unter macOS oder Linux ausgeführt. Sie müssen plattformspezifischen Code bereitstellen und eine ausführbare Datei für jede Plattform kompilieren.

Berücksichtigen Sie auch, wenn eine Bibliothek, auf die Sie verwiesen haben, plattformspezifische Abhängigkeiten bereitstellt, Ihre App möglicherweise nicht auf jeder Plattform ausgeführt wird. Wenn Sie jedoch eine bestimmte Plattform veröffentlichen und als Ziel festlegen, werden die plattformspezifischen Abhängigkeiten eines NuGet-Pakets in den Veröffentlichungsordner kopiert.

Um sicherzustellen, dass Ihre App mit ihren systemeigenen Abhängigkeiten veröffentlicht wird, veröffentlichen Sie sie für eine bestimmte Plattform:

dotnet publish -c Release -r <RID>

Eine Liste der Laufzeit-IDs finden Sie im Rid-Katalog (Runtime Identifier).

Frameworkabhängige Bereitstellung

Frameworkabhängige Bereitstellung ist der Standardmodus, wenn Sie entweder über die CLI oder Visual Studio veröffentlichen. In diesem Modus wird ein plattformspezifischer ausführbarer Host erstellt, um Ihre plattformübergreifende App zu hosten. Der Dateiname der ausführbaren Hostdatei variiert pro Plattform und wird mit einem ähnlichen Namen benannt <PROJECT-FILE>.exe. Sie können diese ausführbare Datei direkt ausführen, anstatt sie aufzurufen dotnet <PROJECT-FILE>.dll. Dies ist weiterhin eine akzeptable Möglichkeit zum Ausführen der App.

Ihre App ist für eine bestimmte Version von .NET konfiguriert. Diese gezielte .NET-Laufzeit muss sich in der Umgebung befinden, in der Ihre App ausgeführt wird. Wenn Ihre App beispielsweise auf .NET 9 ausgerichtet ist, muss für jede Umgebung, auf der Ihre App ausgeführt wird, die .NET 9-Laufzeit installiert sein.

Durch das Veröffentlichen einer frameworkabhängigen Bereitstellung wird eine App erstellt, die automatisch auf den neuesten .NET-Sicherheitspatch weitergeleitet wird, der in der Umgebung verfügbar ist, in der die App ausgeführt wird. Weitere Informationen zur Versionsbindung zur Kompilierung finden Sie unter Auswählen der zu verwendenden .NET-Version.

Vorteile

• Kleine Bereitstellung: Nur die App und ihre Abhängigkeiten werden verteilt. Die Umgebung, in der die App ausgeführt wird, muss bereits die .NET-Laufzeit installiert haben.
• Plattformübergreifend: Die App und alle . NET-basierte Bibliothek wird auf anderen Betriebssystemen ausgeführt.
• Verwendet die neueste gepatchte Laufzeit: Die App verwendet die neueste in der Umgebung installierte Laufzeit.

Benachteiligungen

• Erfordert die Vorabinstallation der Laufzeit: Die App kann nur ausgeführt werden, wenn die Version von .NET, auf die sie abzielt, bereits in der Umgebung installiert ist.
• .NET kann sich ändern: Die Umgebung, in der die App ausgeführt wird, kann eine neuere .NET-Laufzeit verwenden, wodurch sich das App-Verhalten ändern kann.

Veröffentlichen

dotnet publish -c Release [-r <RID>]

dotnet publish -c Release [-r <RID>] --self-contained false

Konfigurieren des Suchverhaltens der .NET-Installation

In .NET 9 und höheren Versionen können Sie die .NET-Installationssuchpfade der veröffentlichten ausführbaren Datei über die AppHostDotNetSearch eigenschaften konfigurieren AppHostRelativeDotNet .

AppHostDotNetSearch ermöglicht die Angabe eines oder mehrerer Speicherorte, an denen die ausführbare Datei nach einer .NET-Installation sucht:

• AppLocal: Ordner der ausführbaren App-Datei
• AppRelative: Pfad relativ zur ausführbaren App-Datei
• EnvironmentVariable: Wert von Umgebungsvariablen DOTNET_ROOT[_<arch>]
• Global: registrierte und standardmäßige globale Installationsspeicherorte

AppHostRelativeDotNet Gibt den Pfad relativ zur ausführbaren Datei an, die durchsucht wird, wenn AppHostDotNetSearch sie enthält AppRelative.

Weitere Informationen finden Sie unter AppHostDotNetSearch" und AppHostRelativeDotNet"Installationsspeicherortoptionen" in apphost.

Plattformübergreifende DLL-Bereitstellung

Alternativ können Sie Ihre App als plattformübergreifende DLL ohne plattformspezifische ausführbare Datei veröffentlichen. In diesem Modus wird eine <PROJECT-NAME>.dll Datei im Veröffentlichungsausgabeordner erstellt. Um Ihre App auszuführen, navigieren Sie zum Ausgabeordner, und verwenden Sie den dotnet <PROJECT-NAME>.dll Befehl.

So veröffentlichen Sie als plattformübergreifende DLL:

dotnet publish -c Release -p:UseAppHost=false

Eigenständige Bereitstellung

Wenn Sie eine eigenständige Bereitstellung (Self-Contained Deployment, SCD) veröffentlichen, erstellt der Veröffentlichungsprozess eine plattformspezifische ausführbare Datei. Das Veröffentlichen eines SCD umfasst alle erforderlichen .NET-Dateien, um Ihre App auszuführen, enthält aber nicht die systemeigenen Abhängigkeiten von .NET. Diese Abhängigkeiten müssen in der Umgebung vorhanden sein, bevor die App ausgeführt wird.

Durch das Veröffentlichen eines SCD wird eine App erstellt, die nicht auf den neuesten verfügbaren .NET-Sicherheitspatch weitergeleitet wird. Weitere Informationen zur Versionsbindung zur Kompilierung finden Sie unter Auswählen der zu verwendenden .NET-Version.

Vorteile

• .NET-Version steuern: Steuern, welche Version von .NET mit der App bereitgestellt wird.
• Plattformspezifische Zielbestimmung: Da die App für jede Plattform veröffentlicht werden muss, ist klar, wo die App ausgeführt wird.

Benachteiligungen

• Größere Bereitstellungen: Da die App die .NET-Laufzeit und alle Abhängigkeiten enthält, ist die erforderliche Downloadgröße und der erforderliche Festplattenspeicher größer als eine frameworkabhängige Bereitstellung.
• Schwieriger, die .NET-Version zu aktualisieren: Die .NET-Runtime kann nur aktualisiert werden, indem eine neue Version der App veröffentlicht wird.

Veröffentlichen

dotnet publish -c Release -r <RID> --self-contained true

Bereitstellung mit einer Datei

Wenn Sie Ihre App als Bereitstellung mit einer Datei veröffentlichen, werden alle anwendungsabhängigen Dateien in einer einzelnen Binärdatei gebündelt. Dieses Bereitstellungsmodell ist sowohl für frameworkabhängige als auch eigenständige Anwendungen verfügbar, die eine attraktive Option zum Bereitstellen und Verteilen Ihrer Anwendung als einzelne Datei bieten.

Einzeldatei-Apps sind immer betriebssystem- und architekturspezifisch. Sie müssen für jede Konfiguration veröffentlichen, z. B. Linux x64, Linux Arm64, Windows x64 usw.

Vorteile

• Vereinfachte Verteilung: Bereitstellen und Verteilen Ihrer Anwendung als einzelne ausführbare Datei.
• Reduzierte Datei-Clutter: Alle Abhängigkeiten werden gebündelt, sodass nicht mehrere Dateien verwaltet werden müssen.
• Einfache Bereitstellung: Kopieren Sie eine einzelne Datei, um die Anwendung bereitzustellen.

Benachteiligungen

• Größere Dateigröße: Die einzelne Datei enthält alle Abhängigkeiten, wodurch sie größer als einzelne Dateien ist.
• Langsamerer Start: Dateien müssen zur Laufzeit extrahiert werden, was sich auf die Startleistung auswirken kann.
• Plattformspezifisch: Muss separate Dateien für jede Zielplattform veröffentlichen.

Die Bereitstellung mit einer Datei kann mit anderen Optimierungen wie Trimming und ReadyToRun-Kompilierung für eine weitere Optimierung kombiniert werden.

Weitere Informationen zur Bereitstellung mit einer Datei finden Sie in der Bereitstellung mit einer Datei.

Veröffentlichen

dotnet publish -c Release -r <RID> -p:PublishSingleFile=true

Native AOT-Bereitstellung

Die systemeigene AOT-Bereitstellung kompiliert Ihre App direkt in systemeigenem Code, sodass keine Laufzeit erforderlich ist. Diese Veröffentlichungsoption verwendet den eigenständigen Bereitstellungsmodus , da der kompilierte systemeigene Code alles enthalten muss, was zum Ausführen der Anwendung erforderlich ist. Dies führt zu schnelleren Startzeiten und reduzierter Arbeitsspeicherauslastung, bietet jedoch einige Einschränkungen bei unterstützten Features.

Vorteile

• Schneller Start: Zur Laufzeit ist keine JIT-Kompilierung erforderlich, was zu einem schnelleren Start der Anwendung führt.
• Verringerte Speicherauslastung: Geringerer Speicherbedarf im Vergleich zu herkömmlichen .NET-Anwendungen.
• Keine Laufzeitabhängigkeit: Die Anwendung wird ohne .NET-Laufzeitinstallation ausgeführt.
• Kleinere Bereitstellungsgröße: Häufig kleiner als eigenständige Bereitstellung mit der vollständigen Laufzeit.

Benachteiligungen

• Eingeschränkte Frameworkunterstützung: Nicht alle .NET-Features und -Bibliotheken sind mit Native AOT kompatibel.
• Längere Buildzeiten: Die Kompilierung in systemeigenem Code dauert länger als normale Builds.
• Plattformspezifisch: Muss für jede Zielplattform und -architektur separat kompiliert werden.
• Debugbeschränkungen: Komplexere Debugerfahrung im Vergleich zu regulären .NET-Anwendungen.

Weitere Informationen zur nativen AOT-Bereitstellung finden Sie in der nativen AOT-Bereitstellung.

Veröffentlichen

dotnet publish -c Release -r <RID> -p:PublishAot=true

ReadyToRun-Bereitstellung

Wenn Sie Ihre App mit readyToRun-Kompilierung veröffentlichen, werden Die Anwendungsassemblys als ReadyToRun (R2R)-Format kompiliert. R2R ist eine Form der Vorabkompilierung (Ahead-of-Time, AOT), die die Startleistung verbessert, indem der Just-in-Time-Compiler (JUST-in-Time, JIT) reduziert wird, wie die Anwendung geladen wird. Diese Veröffentlichungsoption kann sowohl mit frameworkabhängigen als auch eigenständigen Bereitstellungsmodi verwendet werden.

ReadyToRun-Binärdateien enthalten sowohl IL-Code (Intermediate Language) als auch die systemeigene Version desselben Codes. Während R2R-Binärdateien größer als normale Assemblys sind, bieten sie eine bessere Startleistung.

Vorteile

• Verbesserte Startzeit: Die App verbringt weniger Zeit beim Ausführen des JIT-Compilers beim Start.
• Bessere Leistung bei der ersten Verwendung: Reduzierte Latenz für die erstmalige Ausführung von Codepfaden.
• Kompatibel mit vorhandenem Code: Funktioniert ohne Änderung mit den meisten .NET-Bibliotheken und Frameworks.
• Flexible Bereitstellung: Kann sowohl mit frameworkabhängigen Bereitstellungs - als auch eigenständigen Bereitstellungsmodi kombiniert werden.

Benachteiligungen

• Größere Größe: Die App ist aufgrund von IL- und systemeigenem Code auf dem Datenträger größer.
• Längere Erstellungszeiten: Die Kompilierung dauert mehr Zeit als die Standardveröffentlichung.
• Plattformspezifische Optimierungen: Optimale Leistungsgewinne erfordern spezifische Plattformen.

Veröffentlichen

dotnet publish -c Release -r <RID> -p:PublishReadyToRun=true

Weitere Informationen zur ReadyToRun-Bereitstellung finden Sie unter ReadyToRun-Kompilierung.

Containerbereitstellung

Wenn Sie Ihre App als Container veröffentlichen, packt das .NET SDK Ihre Anwendung und deren Abhängigkeiten in ein Containerimage, ohne dass eine separate Dockerfile-Datei erforderlich ist. Dieser Bereitstellungsmodus erstellt ein vollständiges Containerimage, das auf jeder Containerlaufzeit ausgeführt werden kann, z. B. Docker oder Podman. Die Containerbereitstellung vereinfacht den Containerisierungsprozess, da nicht mehr Dockerfiles geschrieben und verwaltet werden müssen, während optimierte Basisimages bereitgestellt werden.

Ab .NET SDK 8.0.200 ist die Containerunterstützung standardmäßig enthalten und erfordert keine zusätzlichen NuGet-Pakete. Bei Konsolenanwendungen müssen Sie möglicherweise die Containerunterstützung explizit aktivieren, indem Sie die EnableSdkContainerSupport Eigenschaft auf " true.

Vorteile

• Vereinfachte Containerisierung: Es ist nicht erforderlich, Dockerfiles für grundlegende Szenarien zu schreiben oder zu verwalten.
• Optimierte Basisimages: Verwendet von Microsoft bereitgestellte, optimierte Basisimages mit den neuesten Sicherheitsupdates.
• Konsistente Umgebung: Stellt eine konsistente Laufzeitumgebung für Entwicklung, Tests und Produktion sicher.
• Einfache Verteilung: Containerimages können einfach freigegeben und in verschiedenen Umgebungen bereitgestellt werden.
• Plattformisolation: Anwendungen werden in isolierten Containern ausgeführt, wodurch Konflikte zwischen Anwendungen reduziert werden.

Benachteiligungen

• Abhängigkeit der Containerlaufzeit: Die Zielumgebung muss eine Containerlaufzeit installiert haben.
• Imagegröße: Containerimages sind in der Regel größer als andere Bereitstellungsmethoden.
• Lernkurve: Erfordert Kenntnisse von Containerkonzepten und Tools.
• Eingeschränkte Anpassung: Weniger Flexibilität im Vergleich zu benutzerdefinierten Dockerfiles für komplexe Szenarien.

Veröffentlichen

dotnet publish -c Release [-r <RID>] /t:PublishContainer

dotnet publish -c Release [-r <RID>] -p:PublishProfile=DefaultContainer

Weitere Informationen zur Containerbereitstellung finden Sie in der Übersicht über die Erstellung von .NET SDK-Containern.

Weitere Informationen

• .NET Runtime Identifier (RID)-Katalog
• Wählen Sie die zu verwendende .NET-Version aus.