Übersicht über die .NET-Anwendungsveröffentlichung

Mit .NET erstellte Anwendungen können in zwei verschiedenen Modi veröffentlicht werden, und der gewählte Modus beeinflusst, wie ein Benutzer Ihre App ausführt.

Die Veröffentlichung als eigenständige App erzeugt eine Anwendung, die die .NET-Runtime und die Bibliotheken, Ihre Anwendung und zugehörige Abhängigkeiten enthält. Benutzer der Anwendung können diese auf einem Computer ausführen, auf dem die .NET-Runtime nicht installiert ist.

Die Veröffentlichung als frameworkabhängige App erzeugt eine Anwendung, die nur die Anwendung selbst und die zugehörigen Abhängigkeiten umfasst. Benutzer der Anwendung müssen die .NET-Runtime separat installieren.

Beide Veröffentlichungsmodi erzeugen standardmäßig eine plattformspezifische ausführbare Datei. Frameworkabhängige Anwendungen können ohne ausführbare Datei erstellt werden, und sie sind plattformübergreifend.

Wenn eine ausführbare Datei erstellt wird, können Sie die Zielplattform mit einem Runtime-Bezeichner (RID) angeben. Weitere Informationen zu RIDs finden Sie im .NET-RID-Katalog.

Die folgende Tabelle bietet einen Überblick über die Befehle, die zum Veröffentlichen einer App als frameworkabhängige oder eigenständige App verwendet werden, gruppiert nach SDK-Version:

Weitere Informationen finden Sie im Artikel zum .NET-Befehl „dotnet publish“.

Erstellen einer ausführbaren Datei

Ausführbare Dateien sind nicht plattformübergreifend. Sie sind spezifisch für ein Betriebssystem und eine CPU-Architektur. Wenn Sie Ihre App veröffentlichen und eine ausführbare Datei erstellen, können Sie die App als eigenständige oder frameworkabhängige App veröffentlichen. Eine eigenständige App umfasst bei Veröffentlichung die .NET-Runtime gemeinsam mit der App, und Benutzer der App müssen sich keine Gedanken über die Installation von .NET machen, bevor sie die App ausführen. Als frameworkabhängige Apps veröffentlichte Apps enthalten weder die .NET-Runtime noch die zugehörigen Bibliotheken, sondern nur die App- und Drittanbieterabhängigkeiten.

Mit den folgenden Befehlen wird eine ausführbare Datei erstellt:

Erzeugen einer plattformübergreifenden Binärdatei

Beim Veröffentlichen Ihrer App als frameworkabhängige App werden plattformübergreifende Binärdateien in Form von DLL-Dateien erstellt. Die DLL-Datei wird nach Ihrem Projekt benannt. Wenn Sie beispielsweise über eine App namens word_reader verfügen, wird eine Datei mit dem Namen word_reader.dll erstellt. Auf diese Weise veröffentlichte Apps werden mit dem Befehl dotnet <filename.dll> ausgeführt und können auf einer beliebigen Plattform verwendet werden.

Plattformübergreifende Binärdateien können auf beliebigen Betriebssystemen ausgeführt werden, sofern die anvisierte .NET-Runtime bereits installiert ist. Wenn die vorgesehene .NET-Runtime nicht installiert ist, kann die App möglicherweise mit einer neueren Runtime ausgeführt werden, wenn die App für ein Rollforward konfiguriert ist. Weitere Informationen finden Sie unter Von Frameworks abhängige Apps führen einen Rollforward aus.

Über die folgenden Befehle wird eine plattformübergreifende Binärdatei erzeugt:

Veröffentlichen als frameworkabhängige App

Apps, die als frameworkabhängig veröffentlicht werden, sind plattformübergreifend und enthalten die .NET-Runtime nicht. Die Benutzer Ihrer App müssen die .NET-Runtime installieren.

Beim Veröffentlichen einer frameworkabhängigen App werden eine plattformübergreifende Binärdatei als DLL-Datei und eine plattformspezifische ausführbare Datei speziell für Ihre aktuelle Plattform erzeugt. Die DLL-Datei ist plattformübergreifend, die ausführbare Datei hingegen nicht. Wenn Sie beispielsweise eine auf Windows ausgerichtete App namens word_reader veröffentlichen, werden die ausführbare Datei word_reader.exe und die Binärdatei word_reader.dll erstellt. Wenn Sie als Zielplattform Linux oder macOS verwenden, werden eine ausführbare word_reader-Datei und die Binärdatei word_reader.dll erstellt. Weitere Informationen zu RIDs finden Sie im .NET-RID-Katalog.

Die plattformübergreifende Binärdatei Ihrer App kann mit dem Befehl dotnet <filename.dll> auf einer beliebigen Plattform ausgeführt werden. Wenn die App ein NuGet-Paket mit plattformspezifischen Implementierungen verwendet, werden alle Plattformabhängigkeiten gemeinsam mit der App in den Veröffentlichungsordner kopiert.

Sie können eine ausführbare Datei für eine bestimmte Plattform erstellen, indem Sie die -r <RID> --self-contained false-Parameter an den Befehl dotnet publish übergeben. Bei Auslassen des -r-Parameters wird eine ausführbare Datei für Ihre aktuelle Plattform erstellt. Alle NuGet-Pakete, die plattformspezifische Abhängigkeiten für die Zielplattform umfassen, werden in den Veröffentlichungsordner kopiert. Wenn Sie keine plattformspezifische ausführbare Datei benötigen, können Sie <UseAppHost>False</UseAppHost> in der Projektdatei angeben. Weitere Informationen finden Sie unter MSBuild-Referenz für .NET SDK-Projekte – UseAppHost.

Vorteile

• Kleine Bereitstellung
  Nur Ihre App und die zugehörigen Abhängigkeiten werden verteilt. Die .NET-Runtime und die Bibliotheken werden vom Benutzer installiert, und alle Apps verwenden die Runtime gemeinsam.

• Plattformübergreifend
  Ihre App und eine beliebige .NET-basierte Bibliothek werden auf anderen Betriebssystemen ausgeführt. Sie müssen keine Zielplattform für Ihre App definieren. Weitere Informationen zum .NET-Dateiformat finden Sie unter .NET-Assemblydateiformat.

• Verwendung der neuesten gepatchten Runtime
  Die App verwendet die neueste Runtime (innerhalb der vorgesehenen Haupt-/Nebenversion der .NET-Familie), die auf dem Zielsystem installiert ist. Auf diese Weise kann Ihre App automatisch die neueste gepatchte Version der .NET-Runtime nutzen. Dieses Standardverhalten kann außer Kraft gesetzt werden. Weitere Informationen finden Sie unter Von Frameworks abhängige Apps führen einen Rollforward aus.

Nachteile

• Vorinstallation der Runtime erforderlich
  Ihre App kann nur ausgeführt werden, wenn die anvisierte .NET-Version bereits auf dem Hostsystem installiert ist. Sie können ein Rollforwardverhalten für die App konfigurieren, um entweder eine spezifische Version von .NET anzufordern oder eine neuere Version von .NET zuzulassen. Weitere Informationen finden Sie unter Von Frameworks abhängige Apps führen einen Rollforward aus.

• .NET kann sich ändern.
  Es ist möglich, dass die .NET-Runtime und die Bibliotheken auf dem Computer aktualisiert werden, auf dem die App ausgeführt wird. In seltenen Fällen kann dies das Verhalten Ihrer App ändern, wenn Sie die .NET-Bibliotheken verwenden, was bei den meisten Apps der Fall ist. Sie können konfigurieren, wie Ihre App neuere Versionen von .NET verwendet. Weitere Informationen finden Sie unter Von Frameworks abhängige Apps führen einen Rollforward aus.

Die folgenden Nachteile gelten nur für das .NET Core 2.1 SDK.

• Verwenden des Befehls dotnet zum Starten der App
  Benutzer müssen den Befehl dotnet <filename.dll> verwenden, um Ihre App zu starten. Das .NET Core 2.1 SDK erzeugt keine plattformspezifischen ausführbaren Dateien für Apps, die als frameworkabhängige Apps veröffentlicht werden.

Beispiele

Veröffentlichen einer plattformübergreifenden, frameworkabhängigen App. Für Ihre App werden eine ausführbare Datei für Ihre aktuelle Plattform sowie eine DLL-Datei erstellt.

dotnet publish

Veröffentlichen einer plattformübergreifenden, frameworkabhängigen App. Für die App werden eine ausführbare 64-Bit-Datei für Linux und eine DLL-Datei erstellt. Dieser Befehl funktioniert nicht mit dem .NET Core SDK 2.1.

dotnet publish -r linux-x64 --self-contained false

Veröffentlichung einer eigenständigen App

Durch die Veröffentlichung einer eigenständigen App wird eine plattformspezifische ausführbare Datei erzeugt. Der Ausgabeordner der Veröffentlichung enthält alle Komponenten der App, einschließlich .NET-Bibliotheken und Zielruntime. Die App ist von anderen .NET-Apps isoliert und verwendet keine lokal installierte, gemeinsam verwendete Runtime. Der Benutzer Ihrer App muss .NET nicht herunterladen und installieren.

Die ausführbare Binärdatei wird für die angegebene Zielplattform generiert. Wenn Sie beispielsweise über eine App namens word_reader verfügen und eine eigenständige ausführbare App für Windows veröffentlichen, wird die Datei word_reader.exe erstellt. Bei einer Veröffentlichung für Linux oder macOS wird eine word_reader-Datei erstellt. Die Zielplattform und -architektur wird mit dem -r <RID>-Parameter für den Befehl dotnet publish angegeben. Weitere Informationen zu RIDs finden Sie im .NET-RID-Katalog.

Wenn die App plattformspezifische Abhängigkeiten aufweist, z. B. ein NuGet-Paket mit plattformspezifischen Abhängigkeiten, werden diese gemeinsam mit der App in den Veröffentlichungsordner kopiert.

Vorteile

• Steuerung der .NET-Version
  Sie steuern, welche Version von .NET mit Ihrer App bereitgestellt wird.

• Plattformspezifische Zielfestlegung
  Da Sie Ihre App für jede Plattform veröffentlichen müssen, kennen Sie die Ausführungsziele für Ihre App. Wenn .NET eine neue Plattform einführt, können die Benutzer Ihre App erst dann auf dieser Plattform ausführen, wenn Sie eine Version für diese Plattform veröffentlichen. Sie können Ihre App auf Kompatibilitätsprobleme testen, bevor die Benutzer Ihre App auf der neuen Plattform ausführen.

Nachteile

• Größere Bereitstellungen
  Da Ihre App die .NET-Runtime und sämtliche App-Abhängigkeiten enthält, sind die Downloadgröße und der benötigte Festplattenspeicher umfangreicher als bei einer frameworkabhängigen Version.

  Tipp

  Sie können die Größe Ihrer Bereitstellung für Linux-Systeme um etwa 28 MB reduzieren, indem Sie den invarianten Globalisierungsmodus von .NET verwenden. Hierdurch wird Ihre App gezwungen, alle Kulturen wie die invariante Kultur zu behandeln.

  Tipp

  Durch die IL-Kürzung kann die Größe Ihrer Bereitstellung weiter reduziert werden.

• Schwierigere Aktualisierung der .NET-Version
  Die (mit Ihrer App verteilte) .NET-Runtime kann nur durch die Veröffentlichung einer neuen Version Ihrer App aktualisiert werden. Nach Bedarf aktualisiert .NET jedoch kritische Sicherheitspatches für die Frameworkbibliothek auf dem Computer, auf dem Ihre App ausgeführt wird. Sie sind für die gesamte Validierung dieses Sicherheitspatchszenarios verantwortlich.

Beispiele

Veröffentlichung einer eigenständigen App. Es wird eine ausführbare 64-Bit-Datei für macOS erstellt.

dotnet publish -r osx-x64

Veröffentlichung einer eigenständigen App. Es wird eine ausführbare 64-Bit-Datei für Windows erstellt.

dotnet publish -r win-x64

Veröffentlichen mit ReadyToRun-Images

Die Veröffentlichung mit ReadyToRun-Images verbessert die Startzeit der Anwendung zulasten der Erhöhung der Anwendungsgröße. Weitere Informationen zum Veröffentlichen mit ReadyToRun finden Sie unter ReadyToRun.

Vorteile

• Verbesserte Startzeit
  Die Anwendung benötigt weniger Zeit für die JIT-Ausführung.

Nachteile

• Größere Größe
  Die Anwendung ist auf dem Datenträger größer.

Beispiele

Veröffentlichung einer eigenständigen ReadyToRun-App. Es wird eine ausführbare 64-Bit-Datei für macOS erstellt.

dotnet publish -c Release -r osx-x64 -p:PublishReadyToRun=true

Veröffentlichung einer eigenständigen ReadyToRun-App. Es wird eine ausführbare 64-Bit-Datei für Windows erstellt.

dotnet publish -c Release -r win-x64 -p:PublishReadyToRun=true

Siehe auch

• Bereitstellen von .NET-Apps mit der .NET-CLI
• Bereitstellen von .NET-Apps mit Visual Studio
• .NET-Runtime-ID-Katalog (RID)
• Auswählen der zu verwendenden .NET-Version