15. Jul 2024
Lesedauer 16 Min.
Auf der Zielgeraden
Sofware verteilen
.NET MAUI bringt eine App auf verschiedene Plattformen. Dafür muss sich der Entwickler mit den Besonderheiten des jeweiligen Zielsystems beschäftigen.
dotnetpro
Um mit .NET plattformübergreifende Applikationen zu entwickeln, stellt das .NET-Ökosystem das Framework .NET MAUI zur Verfügung. Mit ihm lassen sich Anwendungen für Android und iOS im mobilen Bereich, für Windows und macOS im Desktop-Bereich und mit Unterstützung von Samsung sogar für die TV-Plattform Tizen erstellen. Die Programmlogik und auch das User Interface (UI) können dabei weitgehend aus einer gemeinsamen Quellcodebasis schöpfen. Programmiert wird in C#, die Nutzeroberfläche wird mittels XAML deklariert.Die Technologie von .NET MAUI war schon öfters Thema in der dotnetpro, sodass die grundsätzliche Vorgehensweise bekannt sein sollte. Was bei all dem noch fehlt, ist der letzte Schritt der Entwicklung: das Bereitstellen einer App auf den unterschiedlichen Zielsystemen. Spätestens an dieser Stelle geht es darum, die Besonderheiten eines jeden Systems in den Blick zu nehmen. Trotz einer maximalen Harmonisierung aller Entwicklungsaufgaben bei der plattformübergreifenden Entwicklung bestimmen dann nämlich die Zielsysteme die konkreten Vorgehensweisen. Mit anderen Worten: Der Entwickler muss sich mit den Besonderheiten eines jeden Systems konkret beschäftigen.Die Ausführungen beginnen mit einem Überblick über die üblichen Aufgaben des Software-Deployments, bevor es um das konkrete Vorgehen bei einer .NET-MAUI-App geht.
Software-Deployment
Das Deployment in der Softwareentwicklung bezieht sich auf den Prozess des Veröffentlichens, Installierens, Aktivierens und Betreibens einer Anwendung. Dieser Vorgang ist ein kritischer Schritt im Gesamtprozess der Softwareentwicklung, der nach der Entwicklungs- und Testphase erfolgt.Unabhängig von der konkreten Software und der eingesetzten Technik bei der Entwicklung lassen sich dabei üblicherweise die folgenden Aufgaben ausmachen:- Veröffentlichung und Verteilung: Dieser Schritt umfasst das Paketieren der Software und deren Veröffentlichung auf einem Server oder einer Plattform, von wo aus sie installiert oder direkt genutzt werden kann.
- Konfiguration: Umfasst die Einstellungen für die spezifische Umgebung, in der die Software laufen wird. Dazu können Datenbankverbindungen, Netzwerkeinstellungen und Umgebungsvariablen gehören.
- Automatisierung: Hier geht es um eine mögliche Automatisierung der Deployment-Prozesse mithilfe von Continuous Integration und Continuous-Deployment-Pipelines, um Freigabe und Bereitstellung neuer Versionen zu beschleunigen und Fehler zu reduzieren.
- Überwachung und Wartung: Die laufenden Apps sollten hinsichtlich der Leistung und möglicher Fehler überwacht werden, sofern das aus datenschutzrechtlichen Aspekten kein Problem darstellt. Das erlaubt Hinweise auf mögliche Fehler und vereinfacht Wartungsarbeiten, das heißt das Bereitstellen von Updates und
Patches.
- Kompatibilität und Abhängigkeiten: Es ist sicherzustellen, dass die Software in der Produktionsumgebung wie erwartet funktioniert, einschließlich der Kompatibilität mit dem Betriebssystem, anderen Anwendungen und Bibliotheken. Dieser Übergang ist in praktisch allen Fällen kritisch. In der quasi abgeschotteten Umgebung des Entwicklungssystems funktioniert die App noch wunderbar. Sobald diese in die „raue“ Umgebung der Nutzer entlassen wird, muss sie mit einer Vielzahl von geänderten Rahmenbedingungen zurechtkommen. Dazu zählen beispielsweise unterschiedliche Gerätetypen mit verschiedener Hard- und Softwareausstattung, unsichere und wechselnde Internet- und Netzwerkverbindungen und eine gegenseitige Beeinflussung mit anderer vorhandener Software.
- Skalierbarkeit und Leistung: Die Software muss unter verschiedenen Lastbedingungen effizient und zuverlässig funktionieren. Um dieses Ziel zu erreichen, ist eine sorgfältige Planung ebenso erforderlich wie umfangreiches Testen. Ein Beispiel: Der Zugriff auf 100 Testdatensätze ist in der IDE in Bezug auf Zugriffsgeschwindigkeit und Laufzeitverhalten der Darstellung kein Problem. Wie verhält es sich jedoch, wenn statt 100 plötzlich 100 000 Datensätze zur Auswahl und Anzeige bereitstehen?
- Sicherheit und Datenschutz: Es ist ein bestmöglicher Schutz der Anwendung vor Sicherheitslücken und Angriffen einzurichten. Dieses erfordert eine kontinuierliche Überwachung und die Möglichkeit, regelmäßige Updates auf den Zielsystem bereitzustellen.
- Rollback-Strategien: Gemeint ist hier die Fähigkeit, schnell auf eine vorherige Version zurückgehen zu können, wenn bei einem neuen Deployment Probleme auftreten. Dieser Aspekt ist gerade in Unternehmensanwendungen entscheidend, wenn eine Unterbrechung der Funktionsbereitschaft des Softwaresystems unbedingt zu vermeiden ist.
Zielsysteme im Überblick
Jedes der unterschiedlichen Zielsysteme hat seine Besonderheiten, die mit .NET MAUI zu berücksichtigen sind. Unter dem Gesichtspunkt des Deployment sind das folgende:- Android: Googles Betriebssystem ist für seine Vielfalt an Geräten, Bildschirmauflösungen und Versionen bekannt. Updates auf den Zielsystemen werden von den Lizenznehmern oft nicht umgesetzt, das heißt viele Geräte sind in der Praxis softwaretechnisch nicht auf dem aktuellen Stand. Es müssen Berechtigungen für den Zugriff auf Funktionen oder Ressourcen angefordert werden. Das Hochladen von Apps in den Google Play Store erfordert das Einhalten von Richtlinien und das Erstellen von Assets wie App-Symbole und Screenshots.
- iOS/macOS: Die Veröffentlichung von iOS-Apps erfordert das Einhalten von
- Apples Richtlinien für den App Store. Dies schließt die Überprüfung von Inhalten, Sicherheitsaspekte und Qualitätsstandards ein. iOS/macOS-Apps müssen digital signiert sein, um auf einem Gerät installiert werden zu können. Dies erfordert das Erstellen von Zertifikaten und Profilen in der Apple-Entwicklungskonsole.
- Windows: Es lassen sich Windows-Apps für Windows 10 und Windows 11 erstellen. Das Erstellen von App-Packages ist für die Verteilung von Windows-Apps über den Microsoft Store oder andere Kanäle notwendig; das erfordert auch das Signieren der Anwendung. Windows hat eine eigene Nutzeroberfläche mit spezifischen Designrichtlinien. Sie sollten sicherstellen, dass die App die Windows-Stilrichtlinien respektiert.
Tabelle 1: Unterschiede im Deployment von Desktop-Anwendungen und mobilen Apps
| ||||||||||||||||||||||||||
Bereitstellung aus .NET MAUI
.NET MAUI verwendet – im Gegensatz zu Xamarin – ein Einzelprojektsystem, das heißt alle Quellcodedateien, auch die plattformspezifischen Dateien, werden in einem gemeinsamen Projekt zusammengefasst (Bild 1). Einstellungen und spezifischer Quellcode, beispielsweise Handler für die individuelle Anpassung von User-Interface-Darstellungen, werden in Unterordnern für jede Plattform abgelegt. Über den Weg der Projektkonfiguration lassen sich dann allgemeine Einstellungen für alle Plattformen und individuelle Projekteinstellungen für jede Zielplattform festlegen.
Die Projektstruktur einer .NET-MAUI-App, gegliedert in die verschiedenen Zielsysteme (Bild 1)
Autor
Android-Deployment
Android-Apps werden im Android-Emulator getestet und korrigiert. Dabei lassen sich unterschiedliche Gerätekonfigurationen untersuchen und die App für verschiedene Versionen des Betriebssystems (API-Level) bereitstellen. Ein physisches Gerät ist über USB kabelgebunden anschließbar oder über WLAN anzusprechen. Die vielen Gerätetypen lassen sich so allerdings nur bedingt berücksichtigen; zu groß ist die Vielfalt unterschiedlicher Hard- und Softwarekonfigurationen mit einem Android-System.Eine gute Hilfe kann dagegen der Einsatz von virtuellen Testumgebungen aus der Cloud sein. Sie bieten die Möglichkeit, die App über das Netzwerk auf einer sehr großen Anzahl von unterschiedlichen Geräten einzurichten und deren Lauffähigkeit, mögliche Probleme, Abstürze oder Probleme bei Darstellung des User Interfaces (unterschiedliche Bildschirmgrößen und -auflösungen) zu ermitteln, die Ursachen zu erforschen und die Fehler zu beseitigen.Das Verteilen einer .NET-MAUI-App für Android setzt voraus, dass man ein Android-Paket (.apk) oder ein Android App Bundle, eine AAB-Datei generiert – siehe dazu auch den Kasten APK und AAB.APK und AAB
Eine APK-Datei (die Dateierweiterung .apk steht für „Android Package“) ist das traditionelle Format, das für Verteilung und Installation von Android-Anwendungen verwendet wird. Eine solche Datei enthält alle für die Ausführung einer App notwendigen Dateien und Ressourcen. Dazu gehören der kompilierte Anwendungscode, die Assets (wie Bilder und Sounds), die Manifest-Datei, die alle erforderlichen Berechtigungen und die Anwendungskonfiguration definiert, sowie eventuelle Bibliotheken. Wenn ein Nutzer eine APK-Datei herunterlädt und installiert, erhält er die vollständige Anwendung mit allen ihren Komponenten.
Um eine Android-App auf das Zielgerät der Nutzer zu bekommen, gibt es folgende Ansätze:
- Nutzung eines App Stores: Am bekanntesten ist der Google Play Store. Hier gibt es die meisten Apps und er hat die größte Reichweite. Alternative Stores sind der Amazon App Store und der Samsung Galaxy Store. Tabelle 2 stellt wichtige Eigenschaften einander gegenüber.
Tabelle 2: Unterschiede der Android-App-Stores
|
- Direktes APK-Deployment: Hier wird kein App Store verwendet; das App-Paket wird über alternative Wege bereitgestellt. Die Vorteile sind eine vollständige Kontrolle über den Vertrieb, keine Gebühren oder Prozentsätze für Verkäufe und keine Gestaltungsrichtlinien, außer gesetzlichen Bestimmungen. Allerdings ist eine eigene Vermarktungsstrategie notwendig, da keine Plattform für Sichtbarkeit sorgt. Nutzer müssen die Installation aus unbekannten Quellen erlauben, was ein Sicherheitsrisiko darstellen kann. Die App kann dazu von einer Webseite heruntergeladen werden. Die Ad-hoc-Verteilung erforder das Android-Paketformat (.apk).
- Unternehmensinterne Verteilung: Gemeint ist eine direkte Verteilung der App an Mitarbeitende oder Kunden ohne App Store. Dieser Ansatz eignet sich gut für interne oder B2B-Anwendungen. Es erfordert jedoch die Implementierung oder Konfiguration eines Systems zum Verteilen und Aktualisieren der App und das Verwalten der App-Zugriffe. Unternehmen können Lösungen des Android Enterprise (siehe auch den Kasten Android Enterprise) oder Mobile Device Management (MDM) nutzen.
Android Enterprise
Android Enterprise ist eine von Google entwickelte Initiative, um die Nutzung von Android-Geräten und -Apps im Unternehmensumfeld zu vereinfachen und abzusichern. Es bietet umfassende Tools und APIs zur Verwaltung von Geräten und Apps, die auf die Bedürfnisse von Unternehmen zugeschnitten sind. Android Enterprise unterstützt sowohl große Organisationen als auch kleine und mittlere Unternehmen hinsichtlich Sicherheit, Effizienz und Produktivität. Es gibt folgende Kernfunktionen:
Unabhängig von der konkreten Variante zum Verteilen der App ist das entsprechende App-Paket (.apk) zu erzeugen. Dabei hilft Visual Studio. Über den Menüpunkt Projekt | Optionen | Android lässt sich das Paketformat festlegen (Bild 2). Über den eingebauten Manifest-Editor kann der Entwickler die Einstellungen der Android-Manifest-Datei anpassen (Bild 3). Bei einer .NET-MAUI-App können Sie vom Debug- auf Release-Modus wechseln und über den Projektmappen-Explorer den Eintrag Veröffentlichen wählen. Visual Studio erzeugt das App-Paket und bietet ein Dialogfeld zur Auswahl des Kanals für die Distribution, das heißt Ad-hoc oder Google Play Store an (Bild 4).
Auswahl des Paketformats für Android in Visual Studio (Bild 2)
Autor
Den Distributionskanal für Android auswählen (Bild 4)
Autor
Die Einstellungen für das Android-Manifest in der IDE (Bild 3)
Autor
Danach müssen Sie dise Daten für das Signieren des App-Pakets eingeben. Falls Sie den Googles Play Store wählen, müssen Sie sich bei diesem anmelden, um das Paket hochzuladen. Bei einer Ad-hoc-Distribution wird es für die manuelle Verteilung erstellt.
iOS-Deployment
Beim Deployment von Apps auf die Plattformen iOS und macOS sind einige Besonderheiten zu beachten. Grundsätzlich ist es notwendig, für das Testen und das Erstellen des fertigen App-Pakets einen Mac-PC zur Verfügung zu haben. Visual Studio kann eine direkte Verbindung zu einem Mac über das lokale Netzwerk herstellen (Bild 5). Auf dem Mac-Rechner muss die aktuelle Version der Xcode-IDE installiert sein. Über das Netzwerk und dem Mac-PC besteht nun Zugriff auf die Build-Tools, um das endgültige App-Package für iOS oder macOS zu erstellen. Die App kann zum Testen im iOS-Simulator oder auf einem physischen iPhone ausgeführt werden; Letzteres wird über Kabel oder WLAN mit dem Mac gekoppelt. Visual Studio stellt einen Remote-iOS-Simulator zur Verfügung, der auf den Bildschirm des Windows-PC das Bild des Simulators inklusive einer Bedienmöglichkeit spiegelt. Das Format, das Apple hierbei verwendet, erläutert der Kasten IPA-Datei.
Eine Verbindung von Visual Studio zum Mac-PC herstellen (Bild 5)
Autor
IPA-Datei
Eine IPA-Datei (IPA steht für „iOS App Store Package“) ist ein Archivformat, das Apple für das Verteilen und die Installation von mobilen Apps auf iOS-Geräten verwendet. Die Dateierweiterung .ipa repräsentiert eine iOS-Anwendung. IPA-Dateien sind im Wesentlichen ZIP-Archive, die eine spezifische Struktur und Dateien enthalten, die für die Installation und Ausführung der App auf einem iOS-Gerät erforderlich sind.
Eine Alternative (jedoch kein vollständiger Ersatz) für den Mac Build Host ist die iOS-Bereitstellung mittels sogenanntem Hot Restart. Hot Restart ist nützlich für Entwickler, die auf einem Windows-PC arbeiten und dennoch ihre iOS-Apps effizient entwickeln und testen möchten. Dazu sind einige Voraussetzungen zu erfüllen:
das Debugging verwenden und Änderungen am Code vornehmen. Die Hot-Reload-Funktion ermöglicht Ihnen, Änderungen am Code in Echtzeit zu sehen, ohne die App neu starten zu müssen.Es gibt allerdings einige Einschränkungen zu beachten, das heißt, für bestimmte fortgeschrittene Funktionen und zum Veröffentlichen der App im App Store ist immer noch ein Mac erforderlich. Das bedeutet, dass lediglich eine Debug-Konfiguration auf diese Weise auf dem iOS-Device ausgeführt werden kann.Für die Verteilung einer fertigen iOS-App gibt es wie bei Android mehrere Alternativen:
- Visual Studio 2022 ab Version 17.3
- ein Apple-Entwicklerkonto
- �ein iOS-Gerät
- �iTunes, um sich mit dem iOS-Gerät zu verbinden
das Debugging verwenden und Änderungen am Code vornehmen. Die Hot-Reload-Funktion ermöglicht Ihnen, Änderungen am Code in Echtzeit zu sehen, ohne die App neu starten zu müssen.Es gibt allerdings einige Einschränkungen zu beachten, das heißt, für bestimmte fortgeschrittene Funktionen und zum Veröffentlichen der App im App Store ist immer noch ein Mac erforderlich. Das bedeutet, dass lediglich eine Debug-Konfiguration auf diese Weise auf dem iOS-Device ausgeführt werden kann.Für die Verteilung einer fertigen iOS-App gibt es wie bei Android mehrere Alternativen:
- App-Store: Der App Store ist die primäre und offizielle Plattform für das Verbreiten von iOS-Anwendungen. Entwickler, die den Store nutzen wollen, müssen sich einem Review-Prozess unterziehen, der sicherstellt, dass ihre App den Richtlinien von Apple entspricht. Nach erfolgreicher Überprüfung wird die App einem globalen Publikum zugänglich gemacht. Diese Methode ist ideal für Apps, die für die breite Öffentlichkeit bestimmt sind, da sie maximale Sichtbarkeit und Vertrauen schafft. Allerdings erhebt Apple sowohl eine jährliche Entwicklergebühr als auch eine Provision für Verkäufe im App Store.
- TestFlight: Das ist eine Plattform für Betatests, bei der Entwickler ihre Programme bereits vor der endgültigen Veröffentlichung an bis zu 10 000 Tester verteilen können. Dies ermöglicht es, Rückmeldungen zu sammeln und etwaige Fehler zu beheben. Die Nutzung von TestFlight vereinfacht es erheblich, Tester einzuladen, und ermöglicht es, schnell und effizient Verbesserungen vorzunehmen. Allerdings sind Betatests auf 90 Tage pro Build beschränkt, und auch hier muss ein vereinfachter Review-Prozess durchlaufen werden.
- Ad-hoc-Distribution: Für eine gezieltere Verteilung, etwa für interne Tests oder kleine Nutzergruppen, eignet sich die Ad-hoc-Distribution. Dabei können Entwickler ihre App direkt auf bis zu 100 spezifisch registrierten Geräten pro Jahr installieren. Diese Methode erfordert das manuelle Sammeln und Registrieren der Geräte-IDs (UDID), bietet aber eine hohe Flexibilität und Kontrolle über die Verteilung. Sie ist besonders nützlich für frühe Entwicklungsphasen oder für Apps, die nur einem ausgewählten Nutzerkreis zur Verfügung gestellt werden sollen.
- Enterprise Program: Unternehmen, die ihre Apps ausschließlich intern an Mitarbeiter verteilen möchten, können auf das Enterprise Program zurückgreifen. Dieses erlaubt eine unbegrenzte Verteilung innerhalb der Organisation und umgeht den öffentlichen App Store, wodurch Anwendungen nicht der Öffentlichkeit zugänglich gemacht werden. Das eignet sich hervorragend für interne Tools und Programme, die spezifisch auf die Bedürfnisse eines Unternehmens zugeschnitten sind. Es ist jedoch zu beachten, dass das Enterprise Program mit höheren Kosten verbunden ist und einen sorgfältigen Umgang erfordert, um Sicherheitsrisiken zu vermeiden.
Signierungs- und Bereitstellungsoptionen für iOS (Bild 6)
Autor
Die Möglichkeiten zur Verteilung für iOS (Bild 7)
Autor
Verteilung und Installation für macOS
Das Bereitstellen von Apps für macOS (Desktop) ist mit dem Vorgehen bei iOS-Apps vergleichbar. Es gibt jedoch einige kleinere Unterschiede zu beachten.Zunächst ist es wichtig zu wissen, dass die Apps für macOS als Mac-Catalyst-Anwendung durch .NET MAUI erstellt werden. Mac Catalyst ist eine Technologie, die es ermöglicht, iPad-/iOS-Apps auf den Mac zu bringen. Der Ansatz basiert auf der Idee, dass viele der Technologien in iOS und macOS sehr ähnlich sind. Man kann die Projekte in Xcode so konfigurieren, dass eine Version der App erstellt wird, die auf macOS läuft. Bei der Aktivierung von Catalyst fügt Xcode automatisch die notwendigen Konfigurationen hinzu, um die App auf dem Mac ausführbar zu machen.Für das Verteilen der Anwendung kann der Entwickler zwischen folgenden Varianten auswählen:- Mac App Store: Der Mac App Store ist die zentrale Stelle, um Apps einem breiten Publikum anzubieten. Diese Apps müssen den Review-Prozess durchlaufen und die Richtlinien für Design, Funktionalität und Sicherheit erfüllen.
- Direkter Download: Dieser Ansatz erlaubt die maximale Kontrolle über den Distributionsprozess, ermöglicht eine direkte Beziehung zu den Nutzern und umgeht die Provisionen und Einschränkungen des Mac App Store. Entwickler können die Software als Download-Paket (DMG- oder PKG-Dateien, siehe auch den Kasten
APP-, PKG- und DMG-Dateien) zur Verfügung stellen. Für die Sicherheit und das Vertrauen der Nutzer ist es wichtig, dass diese Pakete korrekt signiert werden.
APP-, PKG- und DMG-Dateien
Eine APP-Datei repräsentiert eine macOS-Anwendung in ihrer ausführbaren Form. Technisch gesehen handelt es sich dabei um ein Anwendungs-Bundle, also einen speziellen Ordner, der alle notwendigen Ressourcen wie Bilder, Icons, lokalisierte Inhalte und Konfigurationsdateien enthält. Das macOS-Dateisystem behandelt diese Bundles als einzelne, klickbare Einheit, wodurch Nutzer die Anwendung einfach durch einen Doppelklick starten können.
- Ad-hoc-Verteilung: Diese Distributionsvariante ist für das Apple Developer Program und das Apple Developer Enterprise Program verfügbar. Sie kann auf bis zu 100 Geräten erfolgen.
Windows-Deployment
.NET MAUI generiert moderne WinUI-3-Anwendungen. Diese können direkt mit Visual Studio erstellt und auf dem Entwicklungsrechner ausgeführt werden. Es ist der schnellste Weg, die grundsätzliche Funktionsweise einer .NET-MAUI-App zu testen. Voraussetzung ist, dass der Entwicklermodus von Window aktiviert ist. Für das Verteilen der App stehen die folgenden Kanäle zur Auswahl:
- �Microsoft Store: Dieser zentrale Marktplatz bietet eine Plattform mit großer Reichweite. Der Microsoft Store vereinfacht den Installations- und Update-Prozess und stellt zudem sicher, dass die Apps sicherheitsgeprüft sind.
- Eigener Kanal: Apps, die im MSIX-Format gebündelt werden, lassen sich auch über eigene Websites oder Unternehmensnetzwerke verteilen. Die Signierung muss man hier eigenständig vornehmen. Genaueres zu diesem Format erläutert der Kasten Das MSIX-Verpackungsformat.
Das MSIX-Verpackungsformat
Das MSIX-Verpackungsformat ist eine moderne Verpackungslösung von Microsoft, die für das Verteilen und die Installation von Desktop- und UWP (Universal Windows Platform)-Anwendungen ab Windows 10 entwickelt wurde.
- Ungepackte App: Es wäre auch möglich, die App als ungepackte Version zu konfigurieren und diese über ein Installationsprogramm eines Drittanbieters zu verteilen. Dies ist die herkömmlich oft eingesetzte Variante der Anwendungsinstallation für Windows-Programme.
Fazit
.NET MAUI ermöglicht es Entwicklern, plattformübergreifende Anwendungen für Windows, macOS, iOS und Android aus einer einzigen Codebasis zu erstellen und diese einzurichten. Für alle Zielsysteme wird der Prozess von der Paketerstellung über die Signierung bis zur eigentlichen Bereitstellung, beispielsweise in einem App-Store, unterstützt. Damit ist es möglich, den Prozess des Deployment für alle Zielsysteme zu beschleunigen.Fussnoten
- Veröffentlichen einer .NET MAUI-App für Android, http://www.dotnetpro.de/SL2408MAUIDeploy1
- Android Studio-Editor: Nutzer-Opt-in für unbekannte Apps und Quellen, http://www.dotnetpro.de/SL2408MAUIDeploy2
- Android Enterprise-Hilfe, http://www.dotnetpro.de/SL2408MAUIDeploy3
- Veröffentlichen einer .NET MAUI-App für iOS, http://www.dotnetpro.de/SL2408MAUIDeploy4
- Veröffentlichen einer .NET MAUI Mac Catalyst-App, http://www.dotnetpro.de/SL2408MAUIDeploy5
- Veröffentlichen einer .NET MAUI-App für Windows, http://www.dotnetpro.de/SL2408MAUIDeploy6
