C#-.NET-Apps mit WinUI 3

Die Windows UI Library (kurz: WinUI 3) [1] gehört als eigener Bestandteil zum Lieferumfang des Windows App SDK [2] [3]. Inzwischen hat Microsoft das Windows App SDK vollständig von den anderen Windows-SDKs entkoppelt und als Open-Source-Software freigegeben. Als eigenständiger Satz von Entwicklungskomponenten und -tools unterstützt WinUI 3 über das Windows App SDK die Programmierung von Desktop-Apps für Windows 11 mit Abwärtskompatibilität bis Windows 10, Oktober-2018-Update (Version 1809, OS Build 17763). Damit positioniert Microsoft WinUI 3 und das Windows App SDK als moderne Entwicklungsplattform mit dem Ziel, die Programmierung von Windows-Apps zu vereinfachen.Softwaretechnisch gesehen handelt es sich bei WinUI um ein UX-Framework (User Experience) für Windows-Desktop-Apps. Dabei greift WinUI auf die Nutzererfahrungen (UX) und die Oberflächengestaltung (UI) von Fluent 2 ([4], siehe auch den ersten Teil dieser Serie unter [5]), dem Microsoft-­eigenen Design-System, zurück. WinUI in Version 3 erweitert das WinUI-Framework zu einem vollständigen UX-Framework für die Programmierung von Desktop-Windows-Apps mit XAML (Extensible Application Markup Language) und C# (.NET 6 und später), aber auch mit C++. Die Verwendung der neuesten UI-Elemente, verbunden mit dem Interaktionsdesign von Fluent, ermöglicht mit WinUI die Programmierung intuitiver, konsistenter und responsiver Benutzungsschnittstellen.

Einordnung von WinUI 3 in die Tool-Landschaft der UI/UX-Werkzeuge

Grundsätzlich ersetzt das Windows App SDK weder das Windows SDK noch die anderen vorhandenen Entwicklungswerkzeuge und APIs wie Universal Windows Platform (UWP), Windows Forms, Windows Presentation Foundation (WPF) oder Desktop-Win32 mit C++. Diese Aussage gilt auch für den eigenständigen Bestandteil WinUI 3 des Windows App SDK. Ein Entwickler erhält so zwar die Wahlfreiheit zwischen den verschiedenen Entwicklungswerkzeugen und deren APIs, allerdings vereinheitlicht letzten Endes nur das Windows App SDK mit WinUI 3 die Programmierung von Desktop-Apps unter Windows 11 und Windows 10 (Bild 1).

Zukünftige Features von Windows werden keine Anpassungen im bisherigen Quellcode beim Einsatz von WinUI 3 in der Programmierung erfordern. Neuerungen von Windows/Fluent 2 können, sobald ihre Veröffentlichung erfolgt ist, in WinUI-Apps verwendet werden. Microsoft legt seinen Schwerpunkt bei der Weiterentwicklung auf Version 3 des WinUI als Subprojekt des Windows App SDK. Mit WinUI erhält der Entwickler sofortigen Zugriff auf zukünftige Innovationen der Windows-Plattform. Zudem ist Microsoft bestrebt, die Unterschiede zwischen den verschiedenen Entwicklungstools beziehungsweise APIs im Lauf der Zeit zu verringern. Deshalb ergänzt das Windows App SDK sowohl WinRT- (Windows Runtime) als auch Win32-APIs (Desktop) und die .NET-APIs, indem es einen gemeinsamen Satz von APIs für die Entwicklung über diese Plattformen hinweg bietet.Da Microsoft seine Ressourcen in der Windows-Welt auf WinUI 3 als natives UI-Framework ausrichtet und WinUI 3 seitens der Architektur unabhängig vom Betriebssystem und dem Windows App SDK ist, sollten Entwickler für neue Apps primär dieses auf Fluent 2 basierende UI/UX-Framework nutzen. Für alle mit Windows Forms, WPF oder Desktop-Win32 vorhandenen Apps besteht dennoch kein Bedarf, diese Apps kurzfristig nach WinUI 3 zu migrieren, da Micro­soft das Ziel verfolgt, die vorhandenen Differenzen baldmöglichst zu beseitigen. Zusätzlich stellt Microsoft mit XAML Islands den Zugriff auf Komponenten des WinUI-Frameworks in WPF und Windows Forms sicher (Bild 1). Somit ermöglicht XAML Islands bei Bedarf den Einsatz neuer, innovativer UI/UX-Controls in allen bestehenden, auf Basis von WPF und Windows Forms entwickelten Apps.

Infrastruktur für die Entwicklung von WinUI-3-Desktop-Apps bereitstellen

Für die Programmierung mit WinUI 3 kommen als Entwicklungssprachen primär C#, XAML und die Entwicklungstools für .NET zum Einsatz. Daher besteht die Infrastruktur für die Programmierung mit WinUI 3 aus Visual Studio 2022 (ab 17.1), aus den im Workload .NET Desktopentwicklung von Visual Studio enthaltenen Tools und APIs sowie den Windows-App-SDK-C#-Vorlagen. Dabei erfordern Ausführung und Test einer WinUI-3-App eine Aktivierung des Entwicklermodus; dieser befindet sich bei den Einstellungen des Windows-Betriebssystems im Bereich Update & Sicherheit.Ein Download von Visual Studio [6] stellt das zugehörige ­Installationsprogramm für Windows bereit: VisualStudioSet­up (VisualStudioSetup.exe). Dieser Download installiert beim erstmaligen Aufruf den Visual Studio Installer und anschließend automatisch als IDE den Visual-Studio-Kern-Editor in der Sprache des laufenden Windows-Systems. Die englische Sprachversion legt die Auswahl von Englisch über das Re­gister Sprachpakete fest. Eine Sprachumstellung erfordert einen Neustart der IDE. Das Einrichten der Infrastruktur für die Win­UI-3-Entwicklung erfolgt am einfachsten über die Visual-Studio-Installer-App. Dazu genügt ein Klick auf den Eintrag .NET Desktopentwicklung in dessen Workload-Register, anschließend zeigt der rechte Fensterbereich Installationsdetails (Bild 2) alle in diesem Workload enthaltenen Komponenten an.

Dort wählt man zusätzlich über die separate Auswahlliste Optional beim Eintrag .NET-Desktopentwicklung die Windows-App-SDK-C#-Vorlagen aus und klickt auf die Installieren-Schaltfläche. Eine korrekte Installation der benötigten Infrastruktur verifiziert Visual Studio über die Menükaskade Extras | Tools und Features abrufen … Es öffnen sich der Visual Studio Installer und das Wird geändert …-Dialogfenster. Dabei zeigt dessen rechter Fensterbereich Installationsdetails beim Eintrag .NET-Desktopentwicklungstools in der Drop-down-Liste optional alle aktuell in Visual Studio installierten Komponenten anhand einer ausgewählten blauen Checkbox an.

Starterprojekt einer C#-.NET-App für WinUI-3-Programmierung anlegen

Nach Aufruf von Visual Studio öffnet ein Klick auf die Kachel Neues Projekt erstellen das zugehörige Dialogfenster. In den rechts stehenden drei Auswahllisten Alle Sprachen, Alle Plattformen und Alle Projekttypen wählt man: C#, Windows und WinUI aus. Damit die Visual-Studio-IDE den Projekttyp WinUI zur Auswahl anbietet, müssen wie zuvor beschrieben die Windows-App-SDK-C#-Vorlagen/Templates in der Infrastruktur für Visual Studio installiert sein. Sobald alle drei oben genannten Festlegungen über die Auswahllisten getroffen sind, bietet Visual Studio drei verschiedene Projekt­typen zur Auswahl an:

• Leere App, verpackt(WinUI 3 in Desktop): Erzeugt ein Projekt für eine Desktop-App mit WinUI-3-Oberfläche, das ein MSIX-Paket zum Erstellen und Verteilen der App enthält.
• Klassenbibliothek(WinUI 3 in Desktop): Erstellt ein Projekt für die Programmierung und Verwaltung einer auf WinUI 3 basierenden Klassenbibliothek für die Wiederverwendung in anderen WinUI-3-Projekten.
• Leere App, verpackt mit Paketerstellungsprojekt für Windows-Anwendungen (WinUI 3 in Desktop): Diese Vorlage generiert zwei voneinander getrennte Projekte – eines mit der auf WinUI basierenden Desktop-App und ein weiteres, das ein WAP-Projekt (Windows Application Packaging) für die Paket-Erstellung mit Visual Studio und die anschließende Verteilung enthält.

Der Programmierer einer WinUI-3-Desktop-App wählt in der Regel den ersten Projekttyp (Leere App, verpackt (WinUI 3 in Desktop)) aus, da dieser kein zusätzliches eigenständiges Packaging-Projekt benötigt. Beim Packaging dieses Projekttyps erzeugt Visual Studio automatisch eine MSIX-Datei. Im Unterschied dazu unterstützt ein Projekt vom Typ Leere App, verpackt mit Paketerstellungsprojekt für Windows-Anwendungen (WinUI 3 in Desktop) die Einbindung mehrerer ausführbarer Programmbestandteile in ein einziges MSIX-Package. Zudem erlaubt dieser Projekttyp die Erstellung einer separaten APPX-Datei für die Verteilung einer App auf UWP-Geräte ohne die Notwendigkeit, den Microsoft Store einbeziehen zu müssen (sogenanntes Sideloading).Ein Doppelklick auf den Projektnamen einer WinUI-3-App im Projektmappen-Explorer von Visual Studio öffnet den Quellcode der .csproj-Konfigurationsdatei. Die dortigen Einträge definieren verschiedene Vorgaben für die WinUI-3-
App, beispielsweise Optionen für deren Packaging. Aktuell stellt die IDE bei diesen Vorgaben als .NET-Runtime die Version 6 ein: <TargetFramework>net6.0-windows10.0.19041.0
</Target­ Framework>. Insofern benötigt die Ausführung der WinUI-3-Desktop-App mindestens .NET Version 6 und seitens des Betriebssystems Windows 10, Version 19041. Nach Auswahl des Projektnamens im Projektmappen-Explorer und dessen Kontextmenü Eigenschaften zeigt die IDE diese Vorgaben sowie weitere über ein Formularfenster in besser lesbarer Form an.

Projekt-Infrastruktur aktualisieren und geeignete Erweiterungen auswählen

Am einfachsten erfolgt die Aktualisierung der Infrastruktur eines WinUI-3-Projekts über den in Visual Studio integrierten NuGet-Package-Manager. Diesen öffnet der Eintrag NuGet-Pakete verwalten … im Projekt-Menü der IDE oder im Kontextmenü des Projektmappen-Explorers. Danach erscheint in Visual Studio der NuGet-Package-Manager; er zeigt in einem eigenen Fenster nach Auswahl des Registerreiters Aktualisierungen alle bereitstehenden Aktualisierungen für die Infrastruktur des aktuell geöffneten Projekts an (Bild 3).

Weitere hilfreiche Tools und Libraries für die Programmierung mit WinUI 3 in Visual Studio finden sich im Marketplace der IDE [7]. Die dort verfügbaren Erweiterungen erläutert ­deren Homepage nach Eingabe von WinUI in deren Suchleiste. Auch die Visual-Studio-IDE enthält eine Suchfunktion für Marketplace-Erweiterungen, welche die Menükaskade Erweiterungen | Erweiterungen verwalten … und Auswahl von Online im linken Fensterbereich öffnet. Die Eingabe von Win­UI in der ganz rechten Suchleiste listet die im Marketplace erhältlichen Erweiterungen auf. Von den frei zugänglichen Erweiterungen für Visual Studio sind die folgenden hervorzuheben:

• Template Studio for WinUI (C#): Ein Programm-Assistent/Wizard von Microsoft für die Neuanlage eines WinUI-Projekts; dieser bietet dem Entwickler bei der Neuanlage eines Projekts verschiedene Vorgaben zur schrittweisen Auswahl an.
• WinUI Essentials: Eine Sammlung von Tools für den Aufbau einer geeigneten Infrastruktur, um mit WinUI effizient zu programmieren. Dazu gehören: Rapid XAML Toolkit, Template Studio for WinUI (C#), Windows App SDK oder XAML Styler.
• WinUICommunity Templates for WinUI: Enthält einen Programm-Assistenten/Wizard für die Neuanlage eines Win­UI-Projekts, der anhand seiner Einstellungen eine Vielzahl von Optionen für den Einstieg in die WinUI-3-Programmierung bietet. Dabei greift diese Erweiterung auf die WinUICommunity-Library und die MVVM-Packages der .NET-Community zurück.
• Uno Platform: Eine Open-Source-Software für die Cross-Plattform-Programmierung von Mobile-, Web- und Desktop-Apps. Damit erschließt die Uno Platform aufgrund ihrer Multiplattformfähigkeit einer mit WinUI programmierten App eine breitere Einsatzbasis.

Aufbau und Struktur einer WinUI-3-App in einem Desktop-Projekt

Ein Desktop-Projekt besteht auf der höchsten Ebene aus einer Projektmappe (in der englischen Terminologie von Visual Studio auch Solution genannt). Der dazu verfügbare Projektmappen/Solution-Explorer zeigt Aufbau und Struktur einer Win­UI-App für ein Desktop-Projekt an. Beides orientiert sich an den gängigen Elementen eines .NET-Projekts sowie am Grundsatz der Trennung zwischen User-Interface (UI), Verarbeitungslogik und den App-Ressourcen. Die zugrunde liegende Projektstruktur unterstützt die Organisation des Quellcodes, indem sie dessen Wiederverwendbarkeit und Wartbarkeit erleichtert. Auf der höchsten Ebene gliedert sich eine Win­UI-Projektmappe in die folgenden fünf Bereiche (Bild 4):

• Abhängigkeiten/Dependencies: Zeigt alle Abhängigkeiten des Projekts zu den verwendeten Entwicklungstools, Libraries, Frameworks, Laufzeitumgebungen und Paketen in einer Liste an.
• Properties: Dient der zentralen Ablage und Verwaltung ­aller projektspezifischen Einstellungen. Dazu gehören die Package-Optionen im Unterbereich PublishProfiles und die launchSettings.json-Datei. Bei launchSettings.json handelt es sich um eine Konfigurationsdatei zur Definition von Umgebungsvariablen sowie zum Starten und Debuggen der WinUI-App.
• Assets: Enthält alle seitens des UI der WinUI-App benötigten visuellen Ressourcen wie Bilder, Icons und Schriften. Als zusätzliche Gliederung bieten sich Unterverzeichnisse an, die sich an den Fenstern der App orientieren.
• App.xaml: Die gleichnamige Datei in diesem Bereich enthält, wie bereits aus ihrem Namen abzuleiten, alle Informationen zu den globalen Ressourcen der gesamten Anwendung. Alle Templates, das Styling und das initiale Markup, welche die App zum Starten benötigt, müssen in die App.xaml-Datei aufgenommen werden. Zusätzlich enthält diese Datei auch Referenzen zu den wiederverwendeten Ressourcen der Anwendung
• MainWindow.xaml: Diese Datei stellt Ressourcen bereit, um mit deren Bestandteilen den Aufbau des WinUI-Objekts MainWindow für Layout und Struktur zu beschreiben – dabei kommt <Window…>/XAML-Markup zum Einsatz. Beim MainWindow handelt es sich um das Hauptfenster der Desktop-App. Nach dem Anwendungsstart zeigt die App als Erstes dieses Hauptfenster an.

Konfigurationsdateien und die Code-behind-Dateien mit ihren Aufgaben

Neben den bereits erläuterten fünf Bereichen enthält das ­Projekt noch zwei weitere Dateien: app.manifest und Package.appxmanifest (Bild 4). Als Konfigurationsdatei stammt
app.manifest aus den Zeiten der frühen Windows-Desktop-Anwendungen; sie definiert verschiedene Attribute oder Einstellungen der App, was die Kompatibilität, Abhängigkeiten zwischen den Ressourcen oder die COM-Registrierung betrifft. Für WinUI-3-Apps wird app.manifest nicht direkt verwendet und kann deshalb vernachlässigt werden.Die Package.appxmanifest enthält als Manifest- beziehungsweise Konfigurationsdatei in Analogie zu app.manifest alle wichtigen Informationen für eine WinUI-3- oder UWP-App, um Packaging und Verteilung der Software durchzuführen. Dazu gehören die Identität der App (Name, Entwickler, Versionsnummer), Zielplattformen, ihre Merkmale wie Systemanforderungen, Berechtigungen, Abhängigkeiten und weitere derartige Eigenschaften.Der App.xaml-Bereich umfasst neben der App.xaml-Datei die zugehörige Code-behind-Datei App.xaml.cs mit einer Partial-C#-Klasse-App. Diese C#-Datei definiert über die Basisklasse Application zusammen mit der App.xaml-Datei die App-Klasse der Anwendung. Visual Studio nennt eine In­stanz der Application-Klasse ein Application-Objekt. In der Code-behind-Datei programmiert der Entwickler alle anwendungsweit zu behandelnden Events, reicht eventuelle Aufrufparameter an das Application-Objekt weiter oder führt spezifische Verarbeitungslogik beim Starten oder Beenden der App durch. Beispielsweise erledigt die standardmäßig in App.xaml.cs vorhandene Methode OnLaunched sämtliche Aufgaben der App, die bei Initialisierung und Start anfallen.Im MainWindow.xaml-Bereich befindet sich auch eine Code-behind-Datei namens MainWindow.xaml.cs mit dem Konstruktor für MainWindow – dem Hauptfenster der App. Wie jede Code-behind-Datei stellt die MainWindow.xaml.cs-Datei die Verbindung zum XAML-Code der Datei MainWindow.xaml her: Beide zusammen bilden die Funktionalität des Hauptfensters der App. Der Quellcode in der Code-behind-Datei baut die Benutzeroberfläche auf und steuert den Zugriff auf Daten sowie Ressourcen. Zudem implementiert dieser C#-Code die Eventhandler, verarbeitet die Events, deklariert das Data Binding, nimmt Berechnungen vor oder führt weitere Aktionen der WinUI-App aus.

Migrationspfad: Mit XAML in die moderne, innovative Fluent-2-Welt

Bei XAML (Extensible Application Markup Language) handelt es sich um eine Markup-Sprache, die Microsoft vor allem für die Programmierung des User-Interface (UI) konzipierte. Erstmals konnte mit XAML für Windows 8 und Windows ­Phone eine portable App erstellt werden. Im Anschluss da­ran kam XAML korrespondierend mit den verschiedenen Windows-Versionen und den damit verbundenen Technologien zum Einsatz. Aufgrund der inhärenten Unterschiede in diesen Technologien entstanden verschiedene Varianten von XAML: für UWP, WPF, WinUI, Xamarin.Forms und .NET MAUI. Lediglich Windows Forms verwendet kein XAML für die Realisierung des UI/UX-Designs.Die mit WinUI 2.x verwendete XAML-Variante entspricht dem in einer UWP-App verwendeten Markup. Allerdings gilt diese Aussage nicht mehr für die Version 3 von WinUI, da diese Version des WinUI-Frameworks vollständig neu (lediglich unter Berücksichtigung einer Kompatibilität zu UWP XAML/WinUI 2 auf der UI-Ebene und nicht im Quellcode) konzipiert wurde. Deshalb kann WinUI-­2-/UWP-XAML und WinUI-3-XAML nicht gleichzeitig innerhalb ein- und derselben App verwendet werden. Dies gilt auch für die anderen UI-Plattformen wie WPF, Windows Forms oder die Win32-Controls.Obwohl WinUI 3 und WPF auf ähnlichen XAML-Konzepten basieren, ist deren Quellcode nicht einfach austauschbar. Ähnlichkeiten verdeutlichen die gemeinsamen Konstrukte der Sprachsyntax. So kennen beide XAML-Varianten beispielsweise Objektelemente, Attribute und Eigenschaften oder nehmen Optimierungen über eine Sammlungssyntax vor. Einige XAML-Elemente verarbeiten direkt Text als ihren Inhalt oder erlauben als Attributname den Einbezug von Ereignissen. Auch unterstützen beide Erweiterungen für die Programmierung zusätzliche Markups oder sogenannte x:-Präfix-Konstrukte.Zudem erlauben alle drei XAML-basierten Frameworks Win­UI 3, WinUI 2/UWP und WPF die Verknüpfung von Ereignissen und Handlern über das Markup mit einer Code-­behind-Datei. Dazu kommen XAML-Markup-Eigenschaften wie Click für Button-Klicks oder TextChanged für Textänderungen zum Einsatz. Um zusätzlich die neuen, moderneren UI/UX-Controls von WinUI 3 der Fluent-2-Welt den Apps einer der anderen UI-Plattformen zugänglich zu machen, hat Microsoft XAML Islands geschaffen (Bild 1): XAML Islands erschließt bestehenden Apps moderne WinUI-3-Oberflächenelemente, um sie zu modernisieren.

WinUI 3 Gallery – eine wertvolle Inspirationsquelle für WinUI-3-Apps

Microsoft liefert über den Windows Store die WinUI 3 Gallery (Bild 5) aus – eine App, die den Einsatzbereich der WinUI-3-Library aufzeigt und visualisiert. Der zugehörige Quellcode der WinUI 3 Gallery befindet sich in einem öffentlich zugänglichen GitHub-Repository [8]. Eine ähnliche App, die WinUI 2 Gallery, hat Microsoft bereits für die Version 2 erstellt. Allerdings zielen die in der WinUI 2 Gallery enthaltenen UI-Controls lediglich auf Windows-10-Apps ab. Um den Inhalt der WinUI 3 Gallery zu erkunden, steht im linken Fensterbereich eine Auswahlliste bereit. Anhand des dortigen Home-Eintrags (Bild 5) hat der Entwickler über die rechts erscheinenden Kacheln direkten Zugriff auf alle zentralen Ressourcen von WinUI 3 im Web.

Den eigentlichen Funktionsumfang der WinUI-3-Library verdeutlichen verschiedene Beispiele, welche die WinUI-3-
Gallery-App nach dem Anklicken des im linken Fensterbereich stehenden Eintrags All samples (Bild 5) in alphabetischer Reihenfolge im rechten Fensterbereich präsentiert. Unterhalb dieses All samples-Eintrags befinden sich weitere Einträge, die die Beispiele geordnet nach verschiedenen UI-Themengebieten wie Basic input, Layout, Menus & toolbars, Navigation oder Styles zugänglich machen. Wählt der Programmierer dort ein bestimmtes Themengebiet aus, zeigt die
WinUI 3 Gallery im rechten Fensterbereich verschiedene passende Fallbeispiele an.So erscheinen beispielsweise nach Auswahl des dortigen Eintrags Date & time im rechten Fensterbereich die in der Win­UI-3-Library verfügbaren Controls wie CalendarDate­Picker, CalenderView, DatePicker und TimePicker. Ein Klick auf eines dieser UI-Controls, zum Beispiel CalendarView(Bild 5), öffnet einen Fensterbereich, der das Control näher erläutert und dem Entwickler dessen Einsatzgebiet verdeutlicht. Dort erhält der Entwickler auch direkten Zugriff auf die zugehörigen Stellen in der Dokumentation und zum Quellcode (XAML, C#). So verweist die Auswahlliste Documentation auf die betroffene Stelle im API des ausgewählten UI-Controls und auch auf die zugrunde liegenden Guidelines.Zusätzlich bietet die WinUI 3 Gallery anhand einer konkreten Realisierung eine Visualisierung des ausgewählten Win­UI-3-Controls (Bild 5), so wie es sich dem Endbenutzer gegenüber in einer WinUI-App präsentiert.Auf den zugrunde liegenden Quellcode dieser Realisierung erhält der Programmierer ebenfalls Zugriff, sobald er auf den unterhalb des UI-Controls stehenden Verweis Source code klickt. Dort erscheint der zum visuellen Fallbeispiel gehörende XAML-Quellcode.Rechts neben der visuellen Darstellung bietet die WinUI-3-Gallery-App bei einigen WinUI-3-Con­trols verschiedene Optionen zur Auswahl an, um deren Auswirkungen zu erkunden. Will der Programmierer die Prinzipien, Regeln und Empfehlungen des Designs näher kennenlernen, so hilft der Eintrag Design guidance (Bild 5) unterhalb des Home-Eintrags im linken Fensterbereich der WinUI 3 Gallery.

Das Theming in einer WinUI-3-App mit dem ­Fluent XAML Theme Editor einrichten

Theming versetzt den Endbenutzer einer App in die Lage, deren visuelles Erscheinungsbild an das aktuell anzutreffende Umfeld (Nacht oder Tageslicht, Sonneneinstrahlung) oder spezielle UI-Elemente an individuelle eigene Vorstellungen anzupassen. Ein Theme auf der Ebene des Betriebssystems, System-Theme genannt, kommt immer dann zum Einsatz, um das Look-and-feel einer größeren Anzahl von Einstellungen für bestimmte Objekte auf einmal zu ändern. Aus dem Blickwinkel des Endbenutzers einer App bezeichnet man ihr Erscheinungsbild auch als Skin oder Visual ­Style. Deshalb nennt sich der damit verbundene Änderungsvorgang auch Styling oder Skinning. Aus Sicht einer App entspricht ein Theme einer Menge vordefinierter Einstellungen, die ihr Aussehen und ihre Funktionalität bestimmt.Dazu gehören Intensität oder Deckkraft von Farben, Schatten oder die Dekorationen der UI-Controls, zum Beispiel der Fensterumrandung, die Ausführungsart von Animationen, die Darstellung des Mauszeigers, des Hintergrunds von Schaltflächen oder von Eingabefeldern. Die verschiedenen zur Einstellung verfügbaren Werte hängen in der Regel von den Vorgaben für das System-Theme des Betriebssystems ab. In der deutschen Version von Windows entspricht der Eintrag Designs bei den Einstellungen der Personalisierung dem System-Theme. Zum System-Theme gehören aber auch vordefinierte systemweite Einstellungen wie höherer Kontrast, mit der Zielrichtung, die Sichtbarkeit der UI-Controls zu verbessern.Innerhalb einer WinUI-3-App erfolgt die Definition Theme-spezifischer Ressourcen über die ResourceDictionary-Einträge in der Datei App.xaml. Eventuell lagert man deren Deklarationen in eigene Theme-Dateien wie LightTheme.xaml oder DarkTheme.xaml aus. Die WinUI-Klasse SystemThemeDetector bestimmt die aktuellen systemweiten Einstellungen oder löst Events bei eventuellen Änderungen aus. Die Codierung der Einträge für das Theming in einer XAML-Datei erleichtert der Fluent XAML Theme Editor von Microsoft [9]. Ursprünglich für die Styles der UWP-Controls programmiert und unter der Bezeichnung UWP XAML Theme Editor freigegeben, lässt sich dieser Editor auch für WinUI-3-Controls einsetzen. Die Installation des Fluent XAML Theme Editors erfolgt über den Microsoft Store.Nach dem App-Start deklariert der Programmierer verschiedene Einstellung für das Theming über die Oberfläche des Fluent XAML Theme Editors. Die Oberfläche teilt sich in die beiden Bereiche Light theme und Dark theme ein (Bild 6). Für die einzelnen in diesen Bereichen enthaltenen WinUI-Con­trols legt der Programmierer Vorgaben anhand der rechts stehenden Registerkarten fest. Derzeit sind Registerkarten für die Einstellungen von Farben und Schatten implementiert. Abschließend generiert der Fluent XAML Theme Editor das zugehörige XAML-Markup durch Klick auf die rechts unten stehende Schaltfläche Export. Daraufhin öffnet sich ein Fenster mit den XAML-Deklarationen, diese kopiert ein Klick auf die Schaltfläche Copy to Clipboard in die Zwischenablage.

Generelle Anwendungsarchitektur für ein WinUI-3-Starterprojekt entwerfen

Eine mit der WinUI-3-Library implementierte C#-.NET-App besitzt eine auf Fluent 2 basierte moderne, innovative Oberfläche. Mithilfe einer solchen Desktop-App verarbeitet der Endbenutzer in der Regel Daten, führt Konsistenzprüfungen durch und reicht die Daten zur Verarbeitung weiter. Für eine solche App eignet sich das Entwurfsmuster MVVM (Model-View-View­Model) als State of the Art der Anwendungsarchitektur. Das Pattern erlaubt eine Arbeitsteilung zwischen den verschiedenen Rollen Entwickler, Tester und UI-Designer, indem es die Darstellung (das UI) von der Logik des UI entkoppelt. Ein Mechanismus zur Bindung der Daten verknüpft View und ViewModel und gewährleistet durch diese lose Kopplung eine funktionale Trennung zwischen Model und View.Gemäß dem MVVM-Muster besteht die Anwendungsarchitektur einer C#-.NET-App aus den obigen drei Komponenten Model-View-ViewModel; diese erweitern die bisherige Struktur des Starterprojekts um zusätzliche Ordner für die Ablage ihrer Quelldateien (Bild 7):

• View: Entspricht dem UI der App und umfasst alle auf der Benutzeroberfläche angezeigten UI-Elemente. Ein automatischer Mechanismus (Data Binding) verknüpft diese UI-Elemente der View mit den Eigenschaften des ViewModel, um Daten anzuzeigen, zu ändern und an das Model weiterzuleiten. Die View besteht aus deklarativem XAML-Mark­up und nur wenig Code-behind. Die Code-behind-Datei greift auf das ViewModel zu und bindet deren Attribute und Befehle. Zur Erhöhung der Wiederverwendbarkeit bietet es sich an, alle potenziell mehrfach verwendbaren Views in ­einem eigenen Ordner Controls(Bild 7) abzulegen, wie im nächsten Abschnitt beschrieben.
• ViewModel: Realisiert den Zustand und das Verhalten der View und dient als Bindeglied zwischen der View und dem Model. Diese Komponente stellt der View allgemein zugängliche Attribute und Befehle zur Verfügung. Dazu greift das ViewModel auf das Model zu und tauscht Informationen mit ihm aus. Die Verbindung zwischen View und View­Model übernimmt das Data Binding in beide Richtungen. Eventuelle Prüfungen zur Konsistenz aktueller Benutzereingaben führt die UI-Logik im ViewModel durch.
• Model: Diese Komponente stellt als Datenzugriffsschicht dem ViewModel die Inhalte der dem Endbenutzer gegenüber anzuzeigenden Daten bereit. Verändert der Benutzer die Inhalte der Daten, so stellt diese Architekturkomponente deren Integrität (Geschäftslogik) für die gesamte Anwendung sicher. Die Geschäftslogik umfasst alle Regeln und Prozesse, die für die Daten in der gesamten Anwendungslandschaft gelten.

Wiederverwendbare Views in einem eigenen Ordner Controls ablegen

Ausgehend vom generierten WinUI-Starterprojekt erfolgt gemäß der Anwendungsarchitektur die Ablage der View des Hauptfensters im bereits vorhandenen Ordner MainWindow.xaml. Zusätzlich kommen alle potenziell wiederverwendbaren UI-Controls in einen separaten Ordner mit dem Namen Controls (Bild 7). Nach Auswahl des Projektnamens KundenVerwaltung legt der Projektmappen/Solution-Explorer diesen Ordner über sein Kontextmenü Hinzufügen | Neuer Ordner an. So stellt beispielsweise eine Menübar im UI eine mehrfach verwendbare View dar. Nach Auswahl des neuen Ordners Controls öffnet das Kontextmenü Hinzufügen | Neues Element … das Dialogfenster Neues Element hinzufügen.Nach Klick auf die Schaltfläche Alle Vorlagen anzeigen bietet Visual Studio die zwei Auswahllisten Installiert und Online an. Die Auswahlliste Installiert enthält beim Eintrag C#-Elemente eine Untergruppe WinUI. Nach Auswahl der WinUI-Untergruppe erscheint rechts davon eine Liste aller verfügbaren WinUI-Elemente. Eine nähere Erläuterung zum Einsatzzweck eines derartigen WinUI-Elements erhält der Programmierer, indem er auf einen der Einträge klickt. Für ein WinUI-User-Control wählt er den Eintrag Benutzersteuer­element (WinUI 3) aus. Die Eingabe von MenuBarFileEdit­Help.xaml im unteren Feld Name und ein Klick auf die Schaltfläche Hinzufügen generiert den zugehörigen Quellcode für diese View-Komponente im Controls-Ordner des Projekts.Der Generator für WinUI-User-Controls von Visual Studio erzeugt für den erforderlichen Quellcode eine XAML- und ­eine zugehörige Code-behind-Datei. Die Code-behind-Datei definiert die Eigenschaften und Eventhandler der in der XAML-Datei enthaltenen UI-Elemente. In der WinUI-3-Gallery-App stellt das Beispiel für eine Menübar den XAML-Quellcode bereit. Den dortigen XAML-Quellcode überträgt ein Copy-and-paste in den Bereich des Grid-Elements der MenuBarFileEditHelp.xaml-Datei. Auf diese neu definierte View im Ordner Controls greift in der MainWindow.xaml-Datei die Anweisung <MenuBarFileEditHelp/> im Bereich des Grid-Elements zu. Ein Klick auf das Glühlampen-Icon im XAML-Editor und Auswahl von XMLNS ”Using:Kunden­Verwaltung.Controls” hinzufügen nimmt den erforderlichen XAML-Namespace in die MainWindow.xaml-Datei auf.

Aufbau und Funktionsweise des Projektassistenten Template Studio

Die Marketplace-Erweiterung Template Studio for WinUI (C#) von Visual Studio generiert ein Starterprojekt für eine C#-.NET-App mit einer MVVM-Architektur. Dazu startet Visual Studio bei der Neuanlage eines Projekts nach Auswahl der Vorlage Template Studio für WinUI den zugehörigen Assistenten/Wizard. Nach Festlegung eines Projektnamens und des Ablageorts für das Projekt zeigt der Assistent links eine Auswahlliste an (Bild 8). Diese linke Auswahlliste untergliedert sich derzeit in fünf verschiedene Gruppen, die wiede­rum verschiedene Vorgaben für das Projekt enthalten.

Bei Auswahl einer dieser Gruppen zeigt der Assistent/Wizard die derzeit für sie implementierten Features in einem ­eigenen mittleren Fensterbereich an. Jede dort verfügbare Funktion präsentiert der Assistent als eigenständige Kachel­oberfläche mit einer kurzen Beschreibung. Bei jeder Kachel befindet sich unterhalb des Beschreibungstexts ein Verweis auf Details (Bild 8). Klickt der Entwickler darauf, öffnet der Assistent ein Dialogfenster, das weitere Informationen zum Umfang und zur Arbeitsweise der jeweiligen Funktion enthält. Nach Auswahl der gewünschten Funktion in einer Gruppe legt ein Klick auf die Schaltfläche Weiter diese Funktion in der Win­UI-App an, und der Assistent/Wizard wechselt in die nächste Gruppe der linken Auswahlliste.Ist der Mauszeiger in einer Gruppe auf eine Kachel positio­niert, die mehrfach in der WinUI-App vorkommen kann, erscheint in ihr links oben ein mit einem weißen Kreis hinterlegtes +-Icon. Ein Klick auf dieses +-Icon nimmt die Funktion erneut in die Spezifikation des Projekts auf, und rechts unten erscheint eine Zahl oder das Wort Hinzugefügt in der jeweiligen Kachel. Dabei bedeutet eine Zahl, wie oft diese Funk­tion in der WinUI-App anzahlmäßig enthalten ist. Im Unterschied dazu weist das Wort Hinzugefügt darauf hin, dass diese Funktion im Projekt nur einmalig vorkommen darf. Rechts neben dem mittleren Fensterbereich Features hinzufügen mit den Kacheloberflächen erscheint im Assistenten/Wizard ein Fensterbereich Details Ihres Projekts (Bild 8). Die dortigen Anzeigen verdeutlichen, welchen funktionalen Umfang die später generierte WinUI-App des Projekts enthalten wird.

Starterprojekt für C#-.NET-App mit ­Anwendungsarchitektur generieren

Template Studio für WinUI (C#) zeigt im rechten Fensterbereich Details für das Projekt alle seitens eines Entwicklers vorgenommene Spezifikationen der WinUI-App für das Projekt an (Bild 8). Dabei handelt es sich um alle gewünschten Vorgaben zum Funktionsumfang des Starterprojekts, die der Entwickler über die Kacheloberflächen bereits anhand seiner Festlegungen getroffen hat. Die Ergebnisse orientieren sich an den im linken Fensterbereich angezeigten Gruppen des Assistenten/Wizards. Erzeugt die getroffene Auswahl an Festlegungen über die Kacheln für eine Gruppe mehrere Instanzen einer Funktion, so zeigt die Projektspezifikation deren Anzahl als Zahl an.Grundsätzlich erlaubt der Fensterbereich Details Ihres Projekts auch nachträgliche Änderungen der bisherigen Festlegungen. Dazu wählt der Entwickler über die dortigen Auswahllisten einen anderen gewünschten Eintrag aus. Alter­nativ löscht ein Klick mit der Maus auf das rote X-Icon sofort ­eine bestimmte Festlegung. Jedoch kann aus einer Änderung ein zusätzliches Löschen bereits getroffener Festlegungen resultieren, die direkt von dieser abhängig sind. Damit der Entwickler nicht versehentlich eine falsche, nicht gewünschte Änderung vornimmt, erscheint ein Dialogfenster, das den Entwickler auf diesen Sachverhalt aufmerksam macht und ­eine explizite Bestätigung verlangt.Sobald alle Einstellungen und Vorgaben für die Spezifikation der WinUI-App passen, genügt ein Klick auf die Schaltfläche Erstellen, und Template Studio für WinUI (C#) generiert das MVVM-Starterprojekt. Die erzeugte README.md-Datei gibt allgemeine Hinweise für das Arbeiten mit dem neuen Projekt. Zusätzlich legt der Assistent/Wizard eine Aufgabenliste (Task List) für die neue WinUI-App an. Um weiter im Projekt zu arbeiten, öffnet der Programmierer diese Aufgabenliste in Visual Studio. Dort befinden sich einzelne für den generierten Quellcode noch zu erledigende Aufgabenstellungen mit ihrer Beschreibung.Klickt man eine der Aufgaben in dieser Aufgabenliste an, verzweigt Visual Studio direkt in die betroffene Zeile im Quellcode der WinUI-App. Um das Projekt mit dem Template-Studio-Assistenten zu erweitern, öffnet der Projektmappen-Explorer diesen erneut über das Kontextmenü Hinzufügen | New Item (Template Studio) und Auswahl des gewünschten Features. Template Studio for WinUI (C#) befindet sich bei Microsoft noch in Entwicklung. So wird derzeit als Entwurfsmuster nur das MVVM Toolkit unterstützt; dabei handelt es sich um das CommunityToolkit.Mvvm-Paket des .NET Community Toolkit. Im Unterschied dazu bietet Tem­plate Studio für WPF oder die UWP-Edition auch die Prism-Library für das MVVM-Pattern an. Sinnvoll wäre es, die generierten Klassen der Komponententests mit zusätzlichem, passendem Quellcode zu versehen.

Mit WinUI 3 und Fluent 2 auf dem Weg in ein erfolgreiches Cloud-Zeitalter

Microsoft präsentierte erstmals Mitte 2021 mit Windows 365 ­einen auf Azure Virtual Desktop aufbauenden neuen Cloud-Dienst. Windows 365 erstellt für den Endbenutzer automatisch einen sogenannten Cloud-PC. Dabei handelt es sich um eine virtuelle Hardware (mit bestimmten, jeweils näher zu spezifizierenden Eigenschaften), die einem bestimmten Benutzer zugewiesen ist. Zu diesen Eigenschaften zählen etwa Anzahl und Typ der Prozessoren, Kapazität an Hauptspeicher (RAM), bereitzustellender Festplattenspeicher et cetera. Inzwischen vermarktet Microsoft Windows 365 per Abonnement und macht so jedem Abonnenten ein Windows-Betriebssystem verbunden mit einer leistungsfähigen Hardware zugänglich.Windows 365 und die dazu definierte virtuelle Hardware bilden zusammen den Cloud-PC, der auf jedem Endgerät läuft, das mindestens über einen Browser verfügt. So erschließt Microsoft über Windows 365 seine Apps auch für An­droid-Geräte, Linux-Hardware wie Chromebooks oder Apple-Hardware wie iPhones, iPads oder Macs. Insgesamt gesehen handelt es sich bei Windows 365 um einen echten Game-Changer in der Welt der Betriebssysteme – ein Windows-Betriebssystem in der Cloud. Was die Entwicklerwelt betrifft, ist Microsoft damit ein Clou gegenüber den Mitbewerbern gelungen: Windows-Apps sind erstmals Cross-Plattform-fähig; sie laufen auf einem als Windows-Client instanzierten Betriebssystem – dem Windows 365 Cloud-PC.Derzeit unterstützt Windows 365 für Apps das IntuneWin-Format (Win32 und MSI), das neue, modernere Paketformat MSIX und über den Windows Store das AppX-Format. Dabei sind die beiden letztgenannten Package-Formate auch für WinUI-3-Apps verfügbar. Die Enterprise-Edition von Windows 10/11 verteilt Apps automatisch im AppX-UWP-Format. Zusammengefasst ergibt sich deshalb für die Anwendungsentwicklung folgendes Fazit: Mit Windows 365 steht dem Benutzer ein Windows-Betriebssystem über die Cloud zur Verfügung. Dieses Cloud-Betriebssystem streamt Apps aus Microsoft Azure auf einen Cloud-PC und bringt so mit WinUI 3 entwickelte und auf Fluent 2 basierende Apps in ein erfolgreiches Cloud-Zeitalter!

Fussnoten

1. GitHub-Repository der Windows UI Library, http://www.dotnetpro.de/SL2406FluentUI1
2. GitHub-Repository des Windows App SDK, http://www.dotnetpro.de/SL2406FluentUI2
3. Neueste Downloads für das Windows App SDK, http://www.dotnetpro.de/SL2406FluentUI3
4. Homepage des Design-Systems Fluent 2, https://fluent2.microsoft.design/
5. Frank Simon, Design-Systeme für UI-Komponenten, dotnetpro 4/2024, Seite 21 ff., http://www.dotnetpro.de/A2404FluentUI
6. Download-Seite von Visual Studio, http://www.dotnetpro.de/SL2406FluentUI4
7. Homepage des Visual Studio Marketplace, https://marketplace.visualstudio.com/
8. GitHub-Repository der WinUI 3 Gallery, http://www.dotnetpro.de/SL2406FluentUI5
9. GitHub-Repository des Fluent XAML Theme Editor, http://www.dotnetpro.de/SL2406FluentUI6