Verteilt und bereit

Mittlerweile gibt es für .NET umfangreiche und gleichzeitig sehr unterschiedliche Bereitstellungsmodelle (englisch: Deployment Models). Sie beschreiben drei unterschiedliche Teilbereiche: Zum einen ist damit gemeint, wie Anwendungen ausgeliefert werden. Des Weiteren beschreiben diese Modelle, wie eine Anwendung zur Verfügung gestellt wird, und drittens, was auf dem Zielsystem vorhanden sein muss, damit die Anwendung ausführbar ist.Mit der fortschreitenden Entwicklung des .NET Frameworks mussten sich auch die Modelle weiterentwickeln oder direkt neue hinzukommen. Nicht immer ist die Voraussetzung einer vorinstallierten .NET-Laufzeitumgebung sinnvoll, und nicht für alle Szenarien ist ein eigenes Installationspaket wünschenswert. Daher bietet .NET einen Fundus an technischen und organisatorischen Modellen an.Zusätzliche CLI-Tools haben zudem dafür gesorgt, dass nicht zwingend eine Entwicklungsumgebung zum Einsatz kommen muss und dass die Flexibilität auf der Kommandozeile deutlich gestiegen ist, da MSBuild nicht mehr direkt angesteuert werden muss.Dieser Artikel gibt einen Überblick über die verschiedenen Bereitstellungsmodelle in .NET, mit Blick speziell auf .NET 5, 6 und 7. Das Modell der Self-contained-Anwendungen wird in einem eigenen Artikel behandelt [1], ebenso wie das Feature des Trimming [2], das speziell bei Self-con­tained-An­wendungen, die als Single-file Deployment ausgeliefert werden, nützlich ist. Um das Thema Trimming geht es zudem in der aktuellen Frameworks-Kolumne [3].

Deployments im Fokus

Mit der Einführung von .NET Core und dem Fortschreiten dieser Entwicklung, bis aktuell hin zum .NET Framework in Version 7, richtete sich der Fokus immer mehr auf Deployments. Damit sind in diesem Kontext die Veröffentlichungen von Anwendungen gemeint, die sich auf Desktop-Plattformen beziehen. Deployments sind zwar auch bei ASP.NET Core oder generell bei Webanwendungen wichtig, laufen dort aber grundlegend anders ab.Da das .NET Framework immer mehr in Richtung Cross-Plattform ausgerichtet wird, geht es zunehmend darum, Anwendungen auf verschiedenen Plattformen bereitzustellen. Zudem kam immer stärker der Wunsch auf, Anwendungen auszuliefern, die kein installiertes Framework mehr voraussetzen. Das funk­tio­niert verständlicherweise nur, wenn alle benötigten Komponenten der Anwendung und des Frameworks direkt mit der Anwendung mitgeliefert werden. Das wiederum hat zur Folge, dass die ausgelieferten Anwendungen sehr umfangreich sind, sodass das Feature des Trimming interessant wird [2].

Bereitstellungsmodelle im Lauf der Zeit

Bereitstellungsmodelle gibt es schon seit den Anfängen des .NET Frameworks. Die unterschiedlichen Möglichkeiten finden allerdings nicht immer eine explizite Erwähnung. Zudem besteht im Cloud-Zeitalter das Potenzial für Verwechslungen.Zu den Bereitstellungsmodellen zählen beispielsweise auch ClickOnce und (MSI-)Installer. ClickOnce kam in früheren Versionen von .NET zum Einsatz. Dieses Modell bot schon früh eine einfache Möglichkeit, Anwendungen direkt aus dem Web oder einem Netzwerk heraus zu installieren und zu aktualisieren. ClickOnce funktioniert bis heute und ist auch weiterhin auswählbar, wenn eine Anwendung erzeugt wird. Bei der breiten Masse der Entwickler scheint das Feature jedoch nie angekommen zu sein.Ein weiteres Bereitstellungsmodell sind Installationspakete, beispielsweise der klassische MSI-Installer. Das ist ein traditionelles Bereitstellungsmodell, das auf dem Microsoft Installer (MSI) basiert und eine umfassendere Kontrolle über die Installation und Deinstallation von Anwendungen bietet. Eine alternative Variante ist Inno Setup [4], ein kostenloses Installationsprogramm für Windows-Programme von Jordan Russell und Martijn Laan. Inno Setup wurde erstmals 1997 vorgestellt und kann heute mit vielen kommerziellen Installationsprogrammen in Bezug auf Funktionsumfang und Stabilität mithalten, in Teilen übertrifft es diese sogar.Das .NET Framework bietet mittlerweile zahlreiche Modelle an, die direkt mit Bordmitteln genutzt werden können, dazu Self-contained-Anwendungen. Auch die Technologien und Tools haben sich weiterentwickelt. So ist viel über CLI-Tools realisierbar, und Native AOT bietet gänzlich neue Möglichkeiten für Anwendungen auf Basis von nativem Code.Wenn von Deployment-Modellen die Rede ist, besteht ohne weitere Kenntnis des Kontexts allerdings die Gefahr von Verwechslungen. Denn auch die folgenden Modelle fallen unter den Begriff des Bereitstellungsmodells:

• On-Premises: Direkt auf den lokalen Computern eines Unternehmens installierte und ausgeführte Anwendungen.
• Cloud: Anwendungen werden über eine Cloud-Plattform wie Azure oder AWS bereitgestellt und ausgeführt.
• Hybrid: Eine Kombination aus On-Premises- und Cloud-Deployment, bei der ein Teil der Anwendung in der Cloud und ein Teil auf lokalen Computern bereitgestellt wird.

Diese Modelle gibt es im Cloud-Zeitalter ebenfalls, und sie sind valide. Im Kontext dieses Artikels sind allerdings Bereitstellungsmodelle gemeint, die sich auf die Installation und Nutzung von Desktop-Anwendungen fokussieren (siehe Kasten NuGet als Bereitstellungsmodell). Webanwendungen sind in diesem Artikel ebenfalls kein Thema.

Aktuelle Modelle, Varianten und Tools

Inzwischen stehen zahlreiche Deployment-Modelle und Varianten davon zur Verfügung und finden Unterstützung durch verschiedenste Tools, sowohl durch Entwicklungsumgebungen wie Visual Studio und JetBrains Rider als auch auf der Kommandozeile über CLI-Tools. Grundsätzlich gilt dabei ­eine Aufteilung in zwei Modi. .NET-Anwendungen lassen sich auf Basis dieser zwei Modi veröffentlichen. Der Modus wirkt sich stark darauf aus, wie Nutzer eine Anwendung ausführen.Sehen wir uns zunächst den sogenannten Self-con­tained-Modus an. Wenn eine Anwendung „self-contained“ erstellt wird, also als eigenständige Anwendung veröffentlicht ist, wird diese Anwendung so erzeugt, dass die .NET-Laufzeitumgebung, die Bibliotheken sowie die Anwendung selbst und die Abhängigkeiten enthalten sind. Benutzer der Anwendung können diese anschließend auf einem Computer ausführen, auf dem die .NET-Laufzeitumgebung nicht installiert ist. Hierbei bezeichnet „self-contained“ somit alle Abhängigkeiten, die zur Ausführung einer Anwendung notwendig sind.Wird eine Anwendung dagegen als „framework-dependent“ veröffentlicht, zu Deutsch Framework-abhängig, entsteht eine Anwendung, die lediglich die eigene Anwendung selbst und deren Abhängigkeiten enthält. Die Benutzer der Anwendung müssen die .NET-Laufzeitumgebung separat installieren.Beide Veröffentlichungsmodi erzeugen standardmäßig eine plattformspezifische ausführbare Datei. Framework-abhängige Anwendungen lassen sich zudem ohne ausführbare Datei erstellen. Darüber hinaus sind diese Anwendungen plattformübergreifend. Wenn eine ausführbare Datei erstellt wird, lässt sich die Zielplattform mit einem sogenannten Runtime Identifier (RID) spezifizieren. Weitere Informationen zu RIDs finden Sie weiter unten im Abschnitt zum .NET-RID-Katalog.Die Unterschiede bei den Resultaten verlaufen immer an den Schnittkante zu der Frage, ob wir den Self-contained- oder den Framework-dependent-Modus nutzen möchten. Bei Self-contained-Anwendungen wird immer eine ausführbare Binärdatei erzeugt, die nicht plattformunabhängig sein kann, da diese ausführbare Datei an ein bestimmtes Betriebssystem mit einer bestimmten CPU-Architektur gebunden ist.

Framework-dependent Deployment (FDD)

Wie der Name vermuten lässt, sind Anwendungen im Framework-abhängigen Bereitstellungsmodus vollständig von .NET Core abhängig, das auf dem Zielcomputer installiert sein muss, auf dem eine Anwendung laufen soll. Das Framework-dependent Deployment (FDD) ist der Standard-Bereitstellungsmodus für .NET-Core-Anwendungen. Die Anwendung enthält nur den anwendungsspezifischen Code und externe Abhängigkeiten. Da .NET Core bereits auf dem Zielsystem installiert sein muss, ist die Build-Größe der Anwendung entsprechend klein. Ist eine plattformunabhängige Binärdatei gewünscht, muss das Projekt als Framework-dependent-Anwendung in Form einer DLL erzeugt werden. Diese ist plattformunabhängig und wird über den folgenden Befehl erzeugt:

Ausgeführt wird die Datei anschließend über den Befehl

Wichtig ist, dass die korrekte Version des .NET Frameworks installiert sein muss, da es sich um ein Framework-dependent-Artefakt handelt. Vorteile dieses Modus: Die Anwendung enthält nur den Code und die externen Abhängigkeiten; die endgültige Build-Größe ist entsprechend reduziert. Mehrere Anwendungen können sich zudem eine .NET-Installation teilen.

Framework-dependent Executables (FDE)

Der Modus Framework-dependent Executable (FDE) trägt die ausführbare Datei schon im Namen. Dieser Modus ist seit .NET Core Version 2.2 enthalten und im Prinzip identisch zum FDD-Modus. Während FDD eine DLL-Datei erzeugt und die ausführbare Datei weglässt, da diese nicht plattformunabhängig ist, erzeugt FDE nun ebendiese ausführbare Datei, die auf jedem Zielcomputer ausgeführt werden kann. In diesem Modus ist kein .NET-Dienstprogramm notwendig, um die erzeugte Anwendung auszuführen. Dafür ist der sogenannte AppHost, die ausführbare Datei, zuständig.

Self-contained Deployment (SCD)

„Self-contained“ bezieht sich hier auf die .NET-Laufzeitumgebung. Es wird nicht die allgemeine .NET-Installation auf dem Zielsystem genutzt, sondern der endgültige Anwendungs-Build enthält den gesamten anwendungsspezifischen Code und seine Abhängigkeiten zusammen mit den .NET-Bib­liotheken und der .NET-Laufzeitumgebung. In diesem Modus ist es nicht erforderlich, die .NET-Laufzeitumgebung auf dem Zielsystem zu installieren.Da .NET Core plattformübergreifend ist, können wir unseren Code je nach der Plattform erstellen, auf der die Anwendung ausführbar sein soll. Diese Zielplattformen sind win-x86, win-x64, osx-x64 und linux-x64. Beim SCD ist die endgültige Build-Größe der Anwendung jedoch größer als beim FDD-Modus, da die gesamten .NET-Bibliotheken und die
.NET-Laufzeitumgebung mit ausgeliefert werden müssen. Um dieses Problem anzugehen, gibt es das bereits erwähnte Trimming-Feature, siehe dazu auch [2] und [3].

Der .NET-RID-Katalog und Runtime Package Store

Der Begriff des Runtime Identifier (RID) wurde schon erwähnt. RID-Werte kommen zum Einsatz, um die Zielplattformen zu identifizieren, auf denen eine Anwendung ausgeführt wird. Sie werden von .NET-Paketen verwendet, um plattformspezifische Assets in NuGet-Paketen darzustellen. Beispiele für RIDs sind: linux-x64, ubuntu.14.04-x64, win7-x64 oder osx.10.12-x64. Für die Pakete mit nativen Abhängigkeiten gibt der RID an, auf welchen Plattformen das Paket wiederherstellbar ist.Ein einzelner RID lässt sich im <RuntimeIdentifier>-Element einer Projektdatei festlegen. Mehrere RIDs können als durch Semikolons getrennte Liste im genannten Element der Projektdatei definiert werden. Alternativ steht die Option --runtime zur Verfügung, um mit .NET-CLI-Befehlen wie dotnet build, clean, pack, publish oder restore zum Einsatz zu kommen. Ein Muster für ein konkretes Betriebssystem ist häufig wie folgt aufgebaut:

Zudem existiert ein sogenannter RID-Graph, der auch als Runtime Fallback Graph bezeichnet wird. Letzteres beschreibt den Einsatz dieses Graphen sehr gut: einen Zusammenhang zwischen kompatiblen RIDs herstellen. Wenn als Startpunkt die RID win7-x64 herangezogen wird, dann ist dafür win-x64 ein Fallback, dafür wiederum win und dafür any:

Alle RIDs sind im Paket Microsoft.NETCore.Platforms [5] spezifiziert. Die unterstützten RIDs und der Graph sind in der Datei runtime.json [6] zu finden.Der Runtime Package Store ist eine wichtige Verbesserung im .NET Framework. Ab .NET Core 2.0 ist es möglich, Anwendungen gegen einen bekannten Satz von Paketen, die in der Zielumgebung vorhanden sind, zu paketieren und bereitzustellen. Die Vorteile sind schnellere Bereitstellungen, geringerer Speicherplatzbedarf und in einigen Fällen eine verbesserte Startleistung.Diese Funktion trägt den Namen Runtime Package Store, ein Verzeichnis auf der Festplatte, in dem Pakete gespeichert sind. Unter Windows ist das normalerweise C:/Programme/dotnet/store. Dort befinden sich Unterverzeichnisse für Architekturen und Zielframeworks. Das Dateilayout ähnelt der Art und Weise, wie NuGet Assets auf der Festplatte anordnet. Auf den Zielsystemen lassen sich diese Laufzeitumgebungen über eine Manifestdatei festlegen. Diese kann dann mit dem publish-Befehl zum Bauen einer Anwendung genutzt werden:

Visual Studio und das CLI

Die unterschiedlichen Deployment-Modelle lassen sich sowohl unter Visual Studio als auch per Kommandozeile nutzen. Beispielsweise Framework-dependent- sowie Self-contained-Projekte, jeweils mit oder ohne Abhängigkeiten zu Drittkomponenten. Unter Visual Studio steht in den neueren Versionen, das bedeutet Version 15.7 und später, der Publish-Dialog zur Verfügung. Dort sind alle Optionen für die Veröffentlichung hinterlegt. Der Dialog erlaubt das Anlegen von Profilen, die dann für spätere Deployments unkompliziert wiederverwendet werden können. Näheres zu den Möglichkeiten des Dialogs ist in [1] nachzulesen.Über die Kommandozeile lässt sich eine Anwendung ebenfalls veröffentlichen. Dafür steht das CLI zur Verfügung, das seit der SDK-Version von .NET unterschiedliche Kommandos mit verschiedenen Parametern und Optionen bereitstellt. Für .NET 7 sieht das für einen Framework-dependent-Release wie folgt aus:

Mit AppHost ist hier die ausführbare EXE-Datei gemeint, die als Host erstellt wird, um die Anwendung zu starten. Diese Datei entfällt bei der plattformübergreifenden DLL-Datei. Die folgenden beiden Kommandos erzeugen eine vom installierten .NET Framework abhängige, ausführbare Datei:

Das self-contained darf entfallen, da damit, wenn der Parameter true ist, ein Self-contained Deployment gemeint ist, wie der nachfolgende Befehl zeigt:

Die Einführung der Kommandozeile über das .NET CLI war ein wichtiger Schritt in Richtung Continuous Integration und Continuous Delivery. Schon vor der Einführung ließ sich MSBuild antriggern, das CLI als Abstraktion fügt aber einfachere Befehle und weitere Möglichkeiten hinzu.

Native AOT und ReadyToRun

Bei Veröffentlichung mit der Option Native AOT entsteht ­eine Self-contained-Anwendung, die im Voraus, also Ahead-of-Time (AOT) in nativen Code kompiliert worden ist. Dadurch starten native AOT-Anwendungen sehr schnell und verbrauchen weniger Speicher. Ein weiterer Vorteil ist, dass sich die Anwendung auf Systemen ausführen lässt, auf denen die
.NET-Laufzeitumgebung nicht installiert ist.Die Vorteile von nativem AOT kommen vor allem bei einer großen Anzahl von Instanzen zum Tragen. Dazu zählen Cloud-Infrastrukturen und Hyper-Scale-Dienste. Aktuell steht das Feature nicht für ASP.NET Core zur Verfügung, sondern nur für Konsolenanwendungen.Das native AOT-Bereitstellungsmodell verwendet einen Ahead-of-Time-Compiler, um zum Zeitpunkt der Veröffent­lichung IL-Code in nativen Code zu kompilieren. Native AOT-Apps verwenden keinen Just-in-Time-Compiler (JIT), wenn die Anwendung ausgeführt wird. Native AOT-Anwendungen können in eingeschränkten Umgebungen laufen, in denen ein JIT nicht erlaubt ist. Sie zielen auf eine bestimmte Laufzeitumgebung ab, zum Beispiel Linux x64 oder Windows x64, genau wie die Veröffentlichung einer eigenständigen Anwendung.Wichtig zu wissen ist, dass Native AOT einige Einschränkungen aufweist. Eine Codegenerierung zur Laufzeit, beispielsweise über System.Reflection.Emit, ist nicht möglich. Auch die Unterstützung für das dynamische Laden über Assembly.LoadFile fehlt, ebenso wie die Unterstützung für COM unter Windows, die nicht möglich ist. Zudem erfordert dieses Feature das Trimming, was ebenfalls einige Einschränkungen mit sich bringt.Die Startzeit bei Anwendungen ist praktisch immer ein Thema. Das ist bei vorkonfektionierten Anwendungen, die alle benötigten internen und externen Komponenten mitbringen, nicht anders. Microsoft bietet dazu Features an, um sowohl die Startzeit als auch die Latenzzeit von .NET-Anwendungen zu verbessern. Dazu sind die Assemblies einer Anwendung im sogenannten ReadyToRun-Format (auch Ready2Run oder R2R) zu kompilieren. R2R ist dabei eine Form der eben vorgestellten AOT-Kompilierung. Das hat positive Auswirkungen auf den Start einer Anwendung, aber auch auf die erste Verwendung von Code dieser Anwendung. Durch R2R lässt sich beispielsweise die Antwortlatenz bei der ersten Verwendung des Web API einer ASP.NET-Anwendung verringern.R2R-Binärdateien verbessern die Startleistung, indem sie den Arbeitsaufwand des Just-in-Time-Compilers beim Laden einer Anwendung verringern. Die Binärdateien enthalten ähnlichen nativen Code, wie ihn der JIT-Compiler erzeugen würde. R2R-Binärdateien sind allerdings größer, da sie sowohl Intermediate Language Code (IL-Code), der für einige Szenarien noch benötigt wird, als auch die native Version desselben Codes enthalten. R2R ist nur verfügbar, wenn eine Anwendung veröffentlicht wird, die für bestimmte Laufzeitumgebungen wie Linux x64 oder Windows x64 bestimmt ist. Diese Umgebung wird per RID festgelegt.Um ein Projekt mit ReadyToRun zu kompilieren, wird die Anwendung mit der Eigenschaft PublishReadyToRun auf true veröffentlicht. Entweder über die Kommandozeile per

oder über eine Eigenschaft in den Einstellungen des Projekts:

Die Ahead-of-Time-Kompilierung hat komplexe Auswirkungen auf die Anwendungsleistung, die sich nur schwer vorhersagen lassen. Im Allgemeinen wird die Größe einer Assembly auf das Zwei- bis Dreifache ansteigen. Das hat wiederum negative Auswirkungen auf das Laden ebendieser Assembly von einem Datenträger. Im Gegenzug ist jedoch die Anzahl der zur Laufzeit kompilierten Methoden in der Regel erheblich reduziert. Das Ergebnis ist, dass die meisten Anwendungen, die große Mengen an Code enthalten, durch die Aktivierung von ReadyToRun erhebliche Leistungsvorteile erhalten. Bei nicht so umfangreichen Anwendungen ist die Aktivierung der Option allerdings zu prüfen, da sie recht wahrscheinlich keine große Auswirkung hat. Die .NET-Laufzeitbib­liotheken sind bereits mit ReadyToRun vorkompiliert, sodass sich diese Einstellung grundsätzlich nur auf den eigenen Code auswirkt.

Fazit

Der Artikel hat verschiedene Bereitstellungsmodelle für .NET-Anwendungen aufgezeigt. Primär unterschieden werden die drei Modelle Framework-dependent Deployment (FDD), Self-contained Deployment (SCD) und Framework-dependent Executables (FDE). Mit diesen Modellen lassen sich zahlreiche Deployments für Anwendungen vorbereiten, die unterschiedliche Anwendungsfälle abdecken. Und auch NuGet-Pakete gehören zu diesen Bereitstellungsmodellen, ein Umstand, der schnell vergessen wird.Mit den Modellen hat Microsoft das .NET Framework deutlich flexibler gestaltet, als das in den Anfangstagen des Frameworks der Fall war. Dafür verantwortlich waren sicherlich sowohl die Öffnung für andere Plattformen als auch die Tatsache, dass nicht jedes System und jeder Anwender eine fertige .NET-Installation vorweisen kann. Das ist mit den zusätzlichen Modellen kein Problem mehr.Die weiteren Artikel in diesem Schwerpunkt zu .NET-Bereitstellungsmodellen befassen sich konkret mit den Self-contained- und Single-File-Modellen, die über die Zeit erheblich verbessert wurden. Auch das .NET Trimming wird in einem weiteren Artikel explizit vorgestellt.

Fussnoten

1. Fabian Deitelhoff, Fremdgehen ohne Problem, dotnetpro 4/2023, Seite 8 ff., http://www.dotnetpro.de/A2304SelfContained
2. Fabian Deitelhoff, Schrumpfkur für Code, dotnetpro 4/2023, Seite 18 ff., http://www.dotnetpro.de/A2304Trimming
3. Fabian Deitelhoff, Weg mit dem Ballast, dotnetpro 4/2023, Seite 95 ff., http://www.dotnetpro.de/A2304Frameworks
4. Website zu Inno Setup, https://jrsoftware.org/isinfo.php
5. NuGet-Paket zu Microsoft.NETCore.Platforms, https://www.nuget.org/packages/Microsoft.NETCore.Platforms/
6. runtime.json im Repository zu Microsoft.NETCore.Platforms, http://www.dotnetpro.de/SL2304Deployment1