Übersicht über die .NET-Anwendungsveröffentlichung
Anwendungen, die Sie mit .NET erstellen, können in zwei verschiedenen Modi veröffentlicht werden, und der Modus wirkt sich darauf aus, 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 sie auf einem Computer ausführen, auf dem die .NET-Laufzeit 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-Laufzeitumgebung separat installieren.
Beide Veröffentlichungsmodi erzeugen standardmäßig eine plattformspezifische ausführbare Datei. Frameworkabhängige Anwendungen können ohne ausführbare Dateien erstellt werden, und diese Anwendungen sind plattformübergreifend.
Wenn eine ausführbare Datei erstellt wird, können Sie die Zielplattform mit einem Laufzeitbezeichner (RID) angeben. Weitere Informationen zu RIDs finden Sie im .NET RID Catalog.
Die folgende Tabelle bietet einen Überblick über die Befehle, die zum Veröffentlichen einer App als frameworkabhängige oder eigenständige App verwendet werden:
type | Befehl |
---|---|
Frameworkabhängige ausführbare Datei für die aktuelle Plattform | dotnet publish |
Frameworkabhängige ausführbare Datei für eine bestimmte Plattform | dotnet publish -r <RID> |
frameworkabhängige Binärdatei | dotnet publish |
eigenständige ausführbare Datei | dotnet publish -r <RID> --self-contained |
Weitere Informationen finden Sie im Artikel zum .NET-Befehl „dotnet publish“.
Erstellen einer ausführbaren Datei
Ausführungsdateien sind nicht plattformübergreifend; sie sind an ein Betriebssystem und eine CPU-Architektur gebunden. 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. Die Veröffentlichung einer App, die frameworkabhängig ist, umfasst nicht die .NET-Laufzeitumgebung; nur die App selbst und ihre Drittanbieter-Abhängigkeiten sind enthalten.
Die folgenden Befehle erzeugen eine ausführbare Datei:
type | Befehl |
---|---|
Frameworkabhängige ausführbare Datei für die aktuelle Plattform | dotnet publish |
Frameworkabhängige ausführbare Datei für eine bestimmte Plattform | dotnet publish -r <RID> |
eigenständige ausführbare Datei | dotnet publish -r <RID> --self-contained |
Erstellen Sie eine plattformübergreifende 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 eine App mit dem Namen word_readerhaben, 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 jeder beliebigen Plattform ausgeführt werden.
Plattformübergreifende Binärdateien können auf jedem Betriebssystem ausgeführt werden, solange die zielbezogene .NET-Laufzeit 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.
Sie können die App als plattformspezifische ausführbare Datei oder als plattformübergreifende Binärdatei über dotnet
Befehl ausführen. Es sollte keinen Unterschied im Verhalten der App geben, ganz gleich ob die plattformspezifische ausführbare Datei im Vergleich oder der dotnet
-Befehl für gewöhnliche Server-Apps gestartet wird. Durch das Starten über eine plattformspezifische ausführbare Datei wird eine bessere Integration mit dem zugrunde liegenden Betriebssystem erreicht. Zum Beispiel:
- Es wird der Name der ausführbaren Anwendung in der Prozessliste angezeigt und nicht
dotnet
, was verwirrend sein könnte, falls mehrere vorhanden sind. - Sie können die plattformspezifische ausführbare Datei mit den betriebssystemspezifischen Funktionen anpassen. Weitere Informationen finden Sie in dieser Diskussion über die Konfiguration der Standardstapelgröße unter Windows.
Der folgende Befehl erzeugt eine plattformübergreifende Binärdatei:
type | Befehl |
---|---|
frameworkabhängige, plattformübergreifende Binärdatei | dotnet publish |
Veröffentlichen als frameworkabhängige App
Apps, die als frameworkabhängig veröffentlicht werden, sind plattformübergreifend und enthalten die .NET-Runtime nicht. Der Benutzer Ihrer App muss die .NET-Laufzeit 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. Wenn die App ein NuGet-Paket verwendet, das plattformspezifische Implementierungen enthält, werden Abhängigkeiten für alle Plattformen in den Ordner publish\runtimes\{platform} kopiert.
Die plattformübergreifende Binärdatei Ihrer App kann mit dem Befehl dotnet <filename.dll>
ausgeführt werden und kann auf jeder beliebigen Plattform ausgeführt werden.
Plattformspezifische und frameworkabhängige
Sie können eine frameworkabhängige App veröffentlichen, die plattformspezifisch ist, indem Sie die -r <RID>
Parameter an den dotnet publish
-Befehl übergeben. Die Veröffentlichung auf diese Weise ist identisch mit der frameworkabhängigen Veröffentlichung, außer, dass plattformspezifische Abhängigkeiten unterschiedlich gehandhabt werden. Wenn die App ein NuGet-Paket mit plattformspezifischen Implementierungen verwendet, werden nur die Abhängigkeiten der Zielplattform kopiert. Diese Abhängigkeiten werden direkt in den Ordner publish kopiert.
Technisch gesehen ist die erzeugte Binärdatei plattformübergreifend, indem sie auf eine bestimmte Plattform ausgerichtet ist, aber Ihre App wird nicht garantiert plattformübergreifend ausgeführt. Sie können dotnet <filename.dll>
ausführen, aber die App kann abstürzen, wenn versucht wird, auf plattformspezifische Abhängigkeiten zuzugreifen, die fehlen.
Weitere Informationen zu RIDs finden Sie im .NET RID Catalog.
Vorteile
Kleine Bereitstellung.
Nur Ihre App und ihre Abhängigkeiten werden verteilt. Die .NET-Laufzeit und -Bibliotheken werden vom Benutzer installiert, und alle Apps teilen die Laufzeit.Plattformübergreifend
Ihre App und jede .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. Dies bedeutet, dass Ihre App automatisch die neueste gepatchte Version der .NET-Laufzeit verwendet. Dieses Standardverhalten kann außer Kraft gesetzt werden. Weitere Informationen finden Sie unter Von Frameworks abhängige Apps führen einen Rollforward aus.
Benachteiligungen
Vorinstallation der Runtime erforderlich
Ihre App kann nur ausgeführt werden, wenn die Version von .NET, auf die Ihre App ausgerichtet ist, bereits auf dem Hostsystem installiert ist. Sie können das Roll-Forward-Verhalten für die App so konfigurieren, dass entweder eine bestimmte Version von .NET erforderlich ist oder eine neuere Version von .NET zulässig ist. 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-Laufzeit und -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 die meisten Apps tun. 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.
Beispiele
Veröffentlichen einer App als plattformübergreifende und frameworkabhängige App. Eine ausführbare Datei, die auf Ihre aktuelle Plattform ausgerichtet ist, wird zusammen mit der DLL Datei erstellt. Alle plattformspezifischen Abhängigkeiten werden mit der App veröffentlicht.
dotnet publish
Veröffentlichen einer App als plattformspezifische und frameworkabhängige App. Für die App werden eine ausführbare 64-Bit-Datei für Linux und eine DLL-Datei erstellt. Nur die Abhängigkeiten der Zielplattform werden mit der App veröffentlicht.
dotnet publish -r linux-x64
Veröffentlichung einer eigenständigen App
Durch die Veröffentlichung einer eigenständigen App wird eine plattformspezifische ausführbare Datei erzeugt. Der Ausgabeveröffentlichungsordner enthält alle Komponenten der App, einschließlich der .NET-Bibliotheken und der Ziellaufzeit. Die App ist von anderen .NET-Apps isoliert und verwendet keine lokal installierte freigegebene Laufzeit. Es ist nicht erforderlich, dass der Benutzer Ihrer App .NET herunterlädt und installiert.
Sie können eine eigenständige App veröffentlichen, indem Sie den --self-contained
-Parameter an den dotnet publish
-Befehl übergeben. Die ausführbare Binärdatei wird für die angegebene Zielplattform erstellt. Wenn Sie beispielsweise über eine App mit dem Namen word_readerverfügen und eine eigenständige ausführbare Datei für Windows veröffentlichen, wird eine word_reader.exe Datei erstellt. Bei einer Veröffentlichung für Linux oder macOS wird eine word_reader-Datei erstellt. Die Zielplattform und -architektur wird mit dem parameter -r <RID>
für den befehl dotnet publish
angegeben. Weitere Informationen zu RIDs finden Sie im .NET RID Catalog.
Wenn die App plattformspezifische Abhängigkeiten aufweist, z. B. ein NuGet-Paket mit plattformspezifischen Abhängigkeiten, werden diese zusammen mit der App in den Veröffentlichungsordner kopiert.
Vorteile
Steuerung der .NET-Version
Sie steuern, welche Version von .NET mit Ihrer App bereitgestellt wird.Plattformenspezifische Zielgruppenausrichtung
Da Sie Ihre App für jede Plattform veröffentlichen müssen, wissen Sie, wo Ihre App ausgeführt wird. Wenn .NET eine neue Plattform einführt, können Benutzer Ihre App erst auf dieser Plattform ausführen, wenn Sie eine Version für diese Plattform freigeben. Sie können Ihre App auf Kompatibilitätsprobleme testen, bevor Ihre Benutzer Ihre App auf der neuen Plattform ausführen.
Benachteiligungen
Größere Bereitstellungen
Da Ihre App die .NET-Runtime und alle Ihre App-Abhängigkeiten enthält, ist die Downloadgröße und der erforderliche Festplattenspeicher größer als eine frameworkabhängige Version.Tipp
Sie können die Größe Ihrer Bereitstellung auf Linux-Systemen um ca. 28 MB reduzieren, indem Sie den .NET globalisierungsinvarianten Modusverwenden. 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
.NET Runtime (verteilt mit Ihrer App) kann nur aktualisiert werden, indem eine neue Version Ihrer App veröffentlicht wird.
Beispiele
Veröffentlichung einer eigenständigen App. Es wird eine ausführbare 64-Bit-Datei für macOS erstellt.
dotnet publish -r osx-x64 --self-contained
Veröffentlichung einer eigenständigen App. Es wird eine ausführbare 64-Bit-Datei für Windows erstellt.
dotnet publish -r win-x64 --self-contained
Mit ReadyToRun-Bildern veröffentlichen
Die Veröffentlichung mit ReadyToRun-Images verbessert die Startzeit der Anwendung zulasten der Erhöhung der Anwendungsgröße. Weitere Informationen finden Sie unter ReadyToRun.
Vorteile
- Verbesserte Startzeit
Die Anwendung benötigt weniger Zeit für die JIT-Ausführung.
Benachteiligungen
- 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 --self-contained -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 --self-contained -p:PublishReadyToRun=true