Zum Entwickeln von Desktopanwendungen für Windows 10 haben .NET-Entwickler zahlreiche Möglichkeiten: Windows Forms, WPF, UWP und WinUI. Die Windows UI Library, kurz WinUI, stellt die modernste Variante dar. WinUI ist auch die native UI-Plattform von Windows 10, was bedeutet, dass diverse Teile von Windows 10, wie beispielsweise das Startmenü oder die App für die Einstellungen, mit WinUI entwickelt wurden und werden. Auch die bei Entwicklern beliebte Windows Terminal App [1] ist eine mit WinUI entwickelte Windows-Desktopanwendung. Sie lässt sich über den Microsoft Store installieren.

WinUI ist die Weiterentwicklung des UI Frameworks der Universal Windows Platform (UWP). Mit WinUI wurde das UWP UI Framework von Windows 10 entkoppelt. Das hat verschiedene Vorteile: WinUI kann einen anderen Releasezyklus als Windows 10 haben und zudem lassen sich neueste Controls auch auf älteren Windows-10-Versionen einsetzen. Doch UWP existiert weiterhin, und das ist für viele Entwickler etwas verwirrend. Der Grund dafür ist, dass es sich bei der UWP um weitaus mehr als um ein UI Framework handelt. Um zu verstehen, was genau WinUI ist, muss man auch verstehen, was eigentlich die Universal Windows Platform ist. Gehen wir dieser Frage nach.

Was ist die Universal Windows Platform (UWP)?

Mit Windows 10 hat Microsoft die Universal Windows Platform eingeführt. UWP ist auf allen Geräten verfügbar, auf denen Windows 10 läuft:

• PC
• Xbox
• HoloLens
• Surface Hub
• Internet-of-Things-Geräte (IoT, beispielsweise Raspberry Pi)

Für Entwickler hat Visual Studio eine Projektvorlage mit dem Namen Blank App (Universal Windows), mit der sich eine UWP-Anwendung erstellen lässt, die auf all diesen Geräten läuft. Die Anwendung lässt sich dabei entweder mit .NET/C# oder mit C++ erstellen. Wichtig zu verstehen ist, dass UWP ein nativer Teil von Windows 10 und selbst in C++ geschrieben ist. Das macht das Programmieren einer UWP-App mit reinem C++ möglich, erlaubt es aber auch, eine Anwendung mit .NET/C# zu schreiben, die ganz gewöhnliche .NET-Standard-2.0-Klassenbibliotheken referenzieren kann.

Zum Erstellen von Benutzeroberflächen wird mit UWP die Extensible Application Markup Language (XAML) eingesetzt. XAML ist eine XML-basierte Sprache, die ursprünglich mit der Windows Presentation Foundation (WPF) im Jahr 2006 eingeführt wurde. WPF und UWP haben viele gemeinsame Konzepte wie XAML, Data Binding, Styles, Layout etc. Das bedeutet, dass ein WPF-Entwickler in UWP recht schnell zurechtkommt, und auch umgekehrt findet sich eine UWP-Entwicklerin in WPF schnell zurecht. Allerdings standen all die Innovationen, die mit WPF stattgefunden haben, C++-Entwicklern nicht zur Verfügung, denn zum Erstellen von WPF-Anwendungen muss man .NET/C# verwenden. Mit UWP hat sich das geändert, und C++-Entwickler konnten auch wieder bei der neuesten Technologie mitmischen.

Neben der Möglichkeit, mit .NET/C# oder C++ zu entwickeln, ist ein wichtiges Merkmal von UWP-Anwendungen, dass sie in einer Sandbox laufen. Das bedeutet, dass der Systemzugriff begrenzt ist. Das ergibt Sinn, wenn man bedenkt, dass UWP-Anwendungen auch über den Microsoft Store verteilt werden können. Eine UWP-Anwendung muss ihre Fähigkeiten (Capabilities) in einer Manifest-Datei deklarieren, damit diese sich im Anwendungscode auch nutzen lassen. Das ist ein bekanntes Konzept von mobilen Anwendungen, bei denen man als Benutzer Nachrichten sieht, wie beispielsweise „Diese Anwendung möchte Zugriff auf Ihre Bilder, Ihre Dokumente und Ihre Kontakte“. Bei einer UWP-Anwendung ist das genau gleich. Damit beispielsweise der Zugriff auf das Internet funktioniert, muss das als Capability im Manifest der Anwendung angegeben werden.

Zudem ist ein weiteres wichtiges Merkmal von UWP-Anwendungen, dass sie in einem .zip-basierten Format mit der Dateiendung .appx verpackt werden. Das erlaubt eine saubere Installation und Deinstallation auf Windows-10-Geräten. Nach einer Deinstallation ist die Anwendung sauber entfernt und hinterlässt keine Spuren, wie man das von anderen Installationsvarianten kennt.

Ein weiterer, sehr wichtiger Punkt von UWP ist das sogenannte Activation- und Lifecycle-Management. Dabei geht es darum, die Batterie eines Gerätes zu schonen. Klassische Win32-Anwendungen wie WPF- oder Windows-Forms-Anwendungen laufen immer, wenn der Benutzer sie gestartet hat. D. h., selbst wenn der Benutzer eine WPF-Anwendung minimiert oder zu einer anderen Anwendung wechselt, wird die WPF-Anwendung weiterlaufen und den Prozessor beanspruchen. Das ist natürlich nicht gut für batteriebetriebene Geräte wie Tablets. UWP-Anwendungen lösen dieses Problem mit dem erwähnten Activation- und Lifecycle-Management. Minimiert ein Benutzer eine UWP-App oder navigiert er zu einer anderen Anwendung, wird die UWP-App im Hintergrund automatisch ausgesetzt (suspended). Das ermöglicht es dem System, Ressourcen und somit auch Batterie zu sparen. Navigiert der Benutzer zurück zur UWP-Anwendung, wird sie wieder aktiviert und fortgesetzt.

Wie man also sieht, ist UWP mehr als nur ein UI Framework. Es hat verschiedenste Features wie XAML, Paketierung mit .appx, eine Sandbox, ein Lifecycle-Management etc. Genau aus diesem Grund muss man sich als Entwickler bewusst machen, dass UWP ein sehr weiter Begriff ist. Schauen wir uns ihn daher genauer an.

Was steckt hinter UWP?

Nachfolgend eine Auflistung, was alles unter UWP zu verstehen ist:

1. UWP-App – das ist eine Anwendung, die mit C# oder C++ entwickelt wurde. Die Anwendung verwendet alle anderen Punkte, die in dieser Aufzählung gelistet sind. Visual Studio 2019 enthält zum Erstellen einer UWP-App die Projektvorlage Blank App (Universal Windows). Diese Vorlage ist verfügbar, wenn bei der Visual-Studio-Installation der Workload Universal Windows Platform Development ausgewählt wurde.
2. UWP XAML Framework – das ist der Teil von Windows 10, mit dem die eigene UWP-App gebaut wird. Das UWP XAML Framework enthält XAML und auch die visuelle Schicht, die notwendig ist, um die eigene Anwendung auf den Bildschirm zu zeichnen. Auch gehören Benutzereingaben zum UWP XAML Framework, etwa Ereignisse für Tastatur, Maus und Stift.
3. UWP XAML Controls – das sind die Controls, die in der eigenen UWP-App eingesetzt werden, wie TextBox, CheckBox, Button etc. Diese Controls sind auch Teil von Windows 10.
4. WinRT – steht für Windows Runtime. Das ist das moderne Windows API (= Programmierschnittstelle), das bereits mit Windows 8 eingeführt und mit Windows 10 weiterentwickelt wurde. Es verwendet viele Konzepte aus .NET wie Klassen, Methoden und Properties. Auch verwendet WinRT .NET-Metadaten, um die eigenen Inhalte zu beschreiben. D. h., durch diese Metadaten ist bekannt, welche Klassen und Methoden es in der WinRT gibt. Die WinRT ist Teil von Windows 10 und existiert auf jedem Windows-10-Gerät. Auf PCs ist sie neben dem älteren Windows API namens Win32 verfügbar.
5. UWP Packaging – UWP-Anwendungen werden in einer .appx-Datei paketiert (.zip-basiertes Format), was eine saubere Installation und Deinstallation ermöglicht. Das bedeutet, dass nach einer Deinstallation kein Datenmüll hinterlassen wird.
6. UWP-App-Modell – UWP-Anwendungen laufen in einer Sandbox. Sie müssen ihre Fähigkeiten (Capabilities) deklarieren, um Zugriff auf verschiedene Systemressourcen zu erhalten, wie beispielsweise Zugriff auf die Internetverbindung. Um diese Sandbox zu ermöglichen, muss Windows 10 eine UWP-Anwendung in einer besonderen Form hosten/ausführen. Dieses Hostingmodell wird oft als UWP-App-Modell bezeichnet. Das andere bekannte und traditionelle Hostingmodell ist das Win32-Hostingmodell, was auch als Desktophostingmodell bezeichnet wird. WPF- und Windows-Forms-Anwendungen laufen unter dem Win32-Hostingmodell. Neben der Sandbox ist ein Teil des UWP-App-Modells das Activation- und Lifecycle-Management, was für batteriebetriebene Geräte sehr wichtig ist, da damit Energie gespart wird, wenn die UWP-App nicht im Vordergrund ist.

Hinweis

In diesem Artikel sehen wir uns UWP und WinUI aus der Perspektive eines XAML- und C#-Entwicklers an. Das UWP XAML Framework ist vermutlich der meistgenutzte Weg für .NET-Entwickler, um eine UWP-Anwendung zu erstellen, aber es ist nicht der einzige Weg. Das UWP XAML Framework sitzt in Windows 10 auf dem sogenannten Visual Layer, der selbst wiederum auf DirectX aufsetzt, um die Benutzeroberfläche zu zeichnen. Anstatt somit eine UWP-App mit XAML und C# zu erstellen, könnte man auch DirectX verwenden. Mit React Native for Windows, das auf UWP/WinUI aufbaut, lassen sich sogar HTML und JavaScript zum Erstellen einer UWP-App nutzen.

All diese verschiedenen Bereiche von UWP machen deutlich, dass Entwickler nicht immer dasselbe meinen, wenn sie von UWP sprechen. Sie können sich auf einen der Punkte 1 bis 6 beziehen. Wichtig zu wissen ist, dass all diese Punkte auf jedem Windows-10-Gerät verfügbar sind, egal ob PC, HoloLens, Surface Hub, Xbox oder IoT-Gerät. Das liegt daran, dass UWP ein Teil des Windows-10-Kerns ist. Und genau das führt beim Entwickeln von UWP-Apps zu einem Abhängigkeitsproblem.

Das Abhängigkeitsproblem der UWP XAML Controls in Windows 10

Die UWP XAML Controls sind Teil von Windows 10, was eine starke Abhängigkeit einer UWP-App an das Betriebssystem darstellt. Es bedeutet, dass man als Entwickler in der eigenen UWP-Anwendung nur dann die neuesten UWP XAML Controls und XAML-Features nutzen kann, wenn die Benutzer auch die neueste Version von Windows 10 installiert haben. Das bremst natürlich die Innovation sehr stark. Und jeder, der schon Enterprise-Software entwickelt hat, weiß, dass in Unternehmen eine Aktualisierung von Windows 10 durchaus eine Weile dauern kann. Microsoft hat diese Abhängigkeit entfernt, indem die UWP XAML Controls losgelöst von Windows 10 als NuGet-Paket angeboten werden. Es heißt WinUI, hat die Version 2.x, und lässt sich in einer UWP-App referenzieren. Dadurch können die neuesten XAML Controls eingesetzt werden, ohne dass die Benutzer ihre Windows-10-Version aktualisieren müssen.

Die UWP XAML Controls sind natürlich auch nach wie vor Teil von Windows 10, damit existierende UWP-Apps auch weiterhin ohne das NuGet-Paket funktionieren. Die UWP XAML Controls wurden jedoch von Windows 10 in das WinUI-2.x-NuGet-Paket kopiert; neue Features und neue Entwicklungen finden dort statt.

Das Abhängigkeitsproblem des UWP XAML Framework

Zwar hat Microsoft die Abhängigkeit zwischen einer UWP-App und den in Windows 10 integrierten UWP XAML Controls aufgelöst, doch das UWP XAML Framework ist weiterhin Teil von Windows 10 – und hier gibt es genau die gleiche Art von Abhängigkeit zwischen der eigenen UWP-App und Windows 10. Dass das UWP XAML Framework Teil von Windows 10 ist, bedeutet, dass man nur dann die neuesten Framework-Features nutzen kann, wenn man auch die neueste Windows-10-Version installiert hat. Microsoft hat auch diese Abhängigkeit von Windows 10 entkoppelt und stellt das UWP XAML Framework als NuGet Paket bereit. Es trägt den Namen WinUI 3.0 und ist ein volles UI Framework wie WPF oder Windows Forms. Das WinUI-3.0-NuGet-Paket enthält das UWP XAML Framework und – wie WinUI 2.x – die UWP XAML Controls. WinUI 3.0 wird Open Source auf GitHub [2] entwickelt.

Hinweis

Ein Blick in das GitHub Repository von WinUI 3.0 [2] lohnt sich. Die Issues enthalten Ankündigungen für WinUI Community Calls, was Livevideos auf YouTube sind, die einmal im Monat stattfinden – üblicherweise an jedem dritten Mittwoch im Monat. Jeder kann daran teilnehmen, und das WinUI-Team stellt Neuerungen vor und beantwortet auch Fragen.

WinUI 3.0 einsetzen

Das WinUI-3-NuGet-Paket ist nicht dazu gemacht, es in einer klassischen UWP-App zu referenzieren, die mit der Blank App (Universal Windows)-Projektvorlage in Visual Studio erstellt wurde. Eine solche UWP-App nutzt nach wie vor das UWP XAML Framework, das in Windows 10 existiert, und nicht die entkoppelte Version, die sich im WinUI-3-NuGet-Paket befindet. Um WinUI 3 zu nutzen, muss die sogenannte „Project Reunion“-Visual-Studio-Erweiterung installiert werden, die die Projektvorlagen für WinUI-3-Anwendungen enthält. Nachdem sie installiert wurden, lassen sich zwei Arten von WinUI-3-Anwendungen erstellen:

• Blank App (WinUI 3 in UWP)
• Blank App, Packaged (WinUI 3 in Desktop)

Beide Optionen erstellen eine WinUI-3-Anwendung, die das WinUI-3-NuGet-Paket referenziert. Das bedeutet, dass sowohl das UWP XAML Framework als auch die UWP XAML Controls aus dem NuGet-Paket stammen. Es bedeutet auch, dass man für beide Varianten weitestgehend den identischen XAML- und C#-Code schreibt, da sie dasselbe UWP XAML Framework und auch dieselben UWP XAML Controls aus dem NuGet-Paket verwenden. Der Unterschied zwischen den beiden Projektvorlagen ist das darunterliegende App-Modell. Denn mit WinUI 3 hat man plötzlich die Wahl zwischen UWP und Win32 (auch als Desktop bezeichnet). Und da muss man sich entscheiden:

• WinUI 3 in UWP – erstellt eine UWP-App mit WinUI 3, die quasi im UWP-App-Modell gehostet wird. D. h., sie lässt sich auf verschiedensten Windows-10-Geräten installieren, es gibt die Sandbox, und die App schont aufgrund des Activation- und Lifecycle-Managements die Batterie des Geräts, wenn sie nicht im Vordergrund ist.
• WinUI in Desktop – erstellt eine Win32-App mit WinUI 3. Sie läuft auf dem PC und hat keine Sandbox. Somit kann sie alles machen, was auch eine WPF- oder eine Windows-Forms-Anwendung machen kann, wie beispielsweise das komplette Dateisystem lesen.

Das bedeutet, dass WinUI 3 den Entwicklern von Desktopanwendungen für Windows 10 folgende Auswahlmöglichkeiten gibt:

• Programmiersprache: .NET/C# oder C++
• App-Modell: UWP oder Win32

Das heißt auch im Umkehrschluss, dass das UWP-App-Modell weiterhin ein Teil von Windows 10 bleibt und auch als Teil von Windows 10 weiterentwickelt wird. WinUI 3 enthält lediglich das UWP XAML Framework und die UWP XAML Controls, nicht jedoch das UWP-App-Modell zum Hosten einer UWP-App.

SIE LIEBEN .NET?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Hinweis

WinUI 3 ist die moderne Variante des UWP UI Frameworks. Das Erstellen einer UWP-App mit der Projektvorlage Blank App (Universal Windows) ist der alte Weg für eine UWP-App. Neue UWP-Apps sollten mit WinUI 3 und der Projektvorlage Blank App (WinUI 3 in UWP) erstellt werden.

Was ist Project Reunion?

WinUI 3 ist Teil des sogenannten Project Reunion [3]. Das Projekt von Microsoft hat zum Ziel, sämtliche Windows-APIs über NuGet-Pakete bereitzustellen. Neben WinUI ist auch die sogenannte C#/WinRT Library Teil des Project Reunion. C#/WinRT stellt eine C#-Projektion der nativen, in C++ geschriebenen WinRT dar, die das moderne Windows API von Windows 10 ist und oft auch als UWP API bezeichnet wird. C#-Projektion bedeutet, dass sich die in C++ geschriebene WinRT in C# so verwenden lässt, als sei sie in C# geschrieben worden. Auch die C#/WinRT [4] ist Open Source auf GitHub zu finden. Project Reunion versucht also, Windows-Entwicklern alle Ressourcen als NuGet-Pakete zur Verfügung stehen – unabhängig davon, ob sie mit .NET/C# oder mit C++ programmieren, und unabhängig davon, ob sie UWP oder Win32 als Hostingmodell verwenden. Und WinUI 3 selbst ist Teil dieses Project Reunion.

Die Umgebung für WinUI 3 aufsetzen

Um mit WinUI 3 loszulegen, muss die neueste Visual-Studio-Version installiert werden. Dafür sind im Visual Studio Installer die Workloads .NET Desktop Development und Universal Windows Platform Development auszuwählen. Anschließend sind die Projektvorlagen für WinUI 3.0 zu installieren. Diese Projektvorlagen sind Teil der Project Reunion Visual Studio Extension [5]. Sie lässt sich in Visual Studio über das Hauptmenü Extensions installieren. Abbildung 1 zeigt die installierte Extension in Visual Studio 2019. Diese Schritte zum Aufsetzen der Umgebung lassen sich in der offiziellen Dokumentation nachlesen [6].

Abb. 1: Die Project Reunion Extension enthält die WinUI-3-Projektvorlagen

Die WinUI-3-Projektvorlage für Desktop-Apps

Mit der installierten Project Reunion Extension sind die WinUI-3-Projektvorlagen in Visual Studio verfügbar. Abbildung 2 zeigt die Projektvorlage zum Erstellen einer WinUI-3-Desktopanwendung.

Abb. 2: Die Projektvorlage zum Erstellen einer WinUI-3-Desktop-App

WinUI 3 kann für Desktopanwendungen bereits produktiv eingesetzt werden. Doch wie Abbildung 2 zeigt, gibt es noch keine Projektvorlage für eine „WinUI 3 in UWP“-App. Diese App-Variante ist erst im Preview-Status und kommt später dazu. In diesem Abschnitt wird also folglich eine „WinUI in Desktop“-App erstellt. Die Vorlage heißt Blank App, Packaged (WinUI 3 in Desktop). „Packaged“ bedeutet, dass die Anwendung wie eine UWP-Anwendung paketiert wird, womit sie sich unter Windows 10 sauber installieren und deinstallieren lässt. UWP-Apps haben die Dateiendung .appx und Windows 10 weiß, wie Anwendungen mit dieser Dateiendung installiert und deinstalliert werden. Das dahinterliegende Format wird als MSIX bezeichnet. Das Spannende ist, dass sich nicht nur UWP-Apps, sondern auch klassische Win32-Apps in einem MSIX-Paket verpacken lassen. Dazu hat Visual Studio die eigene Projektvorlage Windows Application Packaging Project. Damit lassen sich WPF- oder auch Windows-Forms-Anwendungen als MSIX-Paket verpacken. Dieses Paket hat dann die Dateiendung .msix, es handelt sich dabei jedoch um das exakt gleiche Format wie das einer UWP-.appx-Datei. Eine WinUI-3-Desktop-App ist somit eine Win32-Anwendung, die automatisch über ein MSIX-Paket bereitgestellt wird. Genau dafür steht das „Packaged“ in der Projektvorlage.

Ein WinUI-3-Projekt erstellen

Im Folgenden wird eine „WinUI 3 in Desktop“-Anwendung mit dem Namen WindowsDeveloperApp erstellt. Abbildung 3 zeigt die erstellte Solution, die zwei Projekte enthält. Das erste Projekt ist das eigentliche Anwendungsprojekt, das in den Dateien MainWindow.xaml und MainWindow.xaml.cs den Code des Hauptfensters enthält. Das zweite Projekt ist das Package-Projekt, das das MSIX-Paket erstellt. Unter Applications ist zu sehen, dass es das Anwendungsprojekt referenziert.

Abb. 3: Die erstellte Solution enthält zwei Projekte

Das Package-Projekt ist jenes, das man in Visual Studio als Startprojekt festlegt. Wird es gestartet, wird die WinUI-3-Anwendung kompiliert, in ein MSIX-Paket verpackt, auf dem Windows-10-Rechner installiert und ausgeführt.

Die einzelnen Dateien

Ein WinUI-3-Projekt ist wie eine UWP-App und wie eine WPF-Anwendung aufgebaut. Es gibt die Dateien App.xaml und App.xaml.cs, die zusammen die Application-Klasse definieren. Daneben gibt es die Dateien MainWindow.xaml und MainWindow.xaml.cs, die zusammen die MainWindow-Klasse definieren, die das Hauptfenster der Anwendung repräsentiert.

Listing 1 zeigt den Inhalt der MainWindow.xaml-Datei. Sie enthält standardmäßig ein StackPanel mit einem Button, der den Text „Click Me“ enthält. Dem Button wurde zudem der Name myButton gegeben, um aus der Code-Behind-Datei (MainWindow.xaml.cs) auf ihn zugreifen zu können. Darüber hinaus wurde ein Event Handler für das Click-Event angegeben.

Listing 1: Die MainWindow.xaml-Datei

<Window
  x:Class="WindowsDeveloperApp.MainWindow"
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  xmlns:local="using:WindowsDeveloperApp"
  xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
  xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
  mc:Ignorable="d">
 
  <StackPanel Orientation="Horizontal" HorizontalAlignment="Center" VerticalAlignment="Center">
    <Button x:Name="myButton" Click="myButton_Click">Click Me</Button>
  </StackPanel>
</Window>

Listing 2 zeigt die Code-Behind-Datei MainWindow.xaml.cs. Darin ist eine MainWindow-Klasse definiert, die von Window ableitet. Window selbst stammt aus dem Namespace Microsoft.UI.Xaml, der zu WinUI 3 gehört. Die MainWindow-Klasse enthält neben einem Konstruktor den Event Handler für das Click-Event des Buttons. Darin wird die Content Property des Buttons auf den Wert Clicked gesetzt. Wird somit die Anwendung ausgeführt, wird ein Button mit dem Text „Click Me“ angezeigt, und wird dieser Button geklickt, ändert sich der Text auf „Clicked“. Abbildung 4 zeigt die laufende Anwendung in Aktion. Dabei wurde der Button bereits angeklickt, wodurch er den Text „Clicked“ enthält.

Listing 2: Die MainWindow.xaml.cs Datei

using Microsoft.UI.Xaml;
namespace WindowsDeveloperApp
{
  public sealed partial class MainWindow : Window
  {
    public MainWindow()
    {
      this.InitializeComponent();
    }
 
    private void myButton_Click(object sender, RoutedEventArgs e)
    {
      myButton.Content = "Clicked";
    }
  }
}

Abb. 4: Die erstellte WinUI-App

Listing 3 zeigt den Inhalt der App.xaml.cs-Datei. Darin ist zu sehen, wie die OnLaunched-Methode der Application-Klasse überschrieben wird. Diese Methode wird aufgerufen, wenn die Anwendung gestartet wird. In der OnLaunched-Methode wird eine Instanz des MainWindow erstellt, mit der Activate-Methode aktiviert und somit angezeigt.

Listing 3: Die App.xaml.cs Datei

public partial class App : Application
{
  public App()
  {
    this.InitializeComponent();
  }
 
  protected override void OnLaunched(Microsoft.UI.Xaml.LaunchActivatedEventArgs args)
  {
    m_window = new MainWindow();
    m_window.Activate();
  }
 
  private Window m_window;
}

In der WinUI-Anwendung lässt es sich jetzt wie in einer UWP-Anwendung programmieren. Allerdings ist der große Unterschied aus Sicht eines Entwicklers, dass es sich hier um eine Win32-Anwendung handelt, da die Projektvorlage WinUI in Desktop genutzt wurde. Somit lässt sich beispielsweise mit den .NET-Dateiklassen aus dem Namespace System.IO das komplette Dateisystem einlesen, falls das notwendig sein sollte. Auch basiert die Anwendung auf .NET 5.0. Das bedeutet, dass sämtliche .NET-5.0-Klassenbibliotheken und somit auch .NET-Standard-2.1-Klassenbibliotheken für diese Anwendung zur Verfügung stehen und genutzt werden können.

Zum Programmieren lässt sich genau wie in UWP und WPF das Model-View-ViewModel-Pattern einsetzen. Entwickler können folglich die aus UWP und WPF bewährten Best Practices auch in WinUI nutzen. Wenn man sich noch einmal bewusst macht, dass WinUI nichts anderes als das UWP UI Framework ist – einfach entkoppelt von Windows 10 –, dann klingt es logisch, dass sämtliche Funktionen aus UWP auch in WinUI vorhanden sind.

Ausblick und Fazit

WinUI 3.0 ist mit Project Reunion 0.5 bereit für den produktiven Einsatz. Microsoft plant das Release von Project Reunion 1.0 laut Roadmap [7] in etwa im Oktober 2021, d. h., sehr wahrscheinlich fällt dieses Release mit dem Erscheinen von .NET 6 zusammen, das für November 2021 geplant ist.

WinUI 3.0 als solches stellt die Zukunft zum Entwickeln moderner Windows-Anwendungen mit .NET/C# und auch mit C++ dar. Insbesondere die Flexibilität bezüglich der Programmiersprache (C# oder C++) und die Flexibilität bezüglich des App-Modells (UWP oder Win32) machen WinUI zu einer fantastischen Wahl. Microsoft positioniert WinUI 3.0 auch als native UI-Plattform von Windows 10. Somit ist es klar, dass dieses UI Framework vorangetrieben wird und hier auch die Innovationen im Windows-Desktop stattfinden werden. Doch WPF-Entwickler können sich entspannt zurücklehnen. Das bestehende Know-how kann mit WinUI weitestgehend wiederverwendet werden, da sowohl WinUI als auch WPF zum Erstellen von Benutzeroberflächen XAML verwenden – und da finden sich in beiden Frameworks sehr ähnliche Konzepte für etwa Layout, Styling und Data Binding. Auch Windows-Forms-Entwickler können sich freuen, denn auch bestehende WPF- und Windows-Forms-Anwendungen lassen sich mit WinUI 3 Controls modernisieren. Die Zukunft wird somit sehr interessant und spannend für Entwickler, die Windows-Desktopanwendungen mit .NET oder mit C++ programmieren möchten.

Links & Literatur

[1] Windows Terminal: https://www.microsoft.com/de-de/p/windows-terminal/9n0dx20hk701

[2] WinUI GitHub Repo: https://github.com/microsoft/microsoft-ui-xaml

[3] Project Reunion GitHub Repo: https://github.com/microsoft/microsoft-ui-xaml

[4] C#/WinRT GitHub Repo: https://github.com/microsoft/CsWinRT 

[5] Project Reunion Visual Studio Extension: https://marketplace.visualstudio.com/items?itemName=ProjectReunion.MicrosoftProjectReunion

[6] Dokumentation zum Aufsetzen der Umgebung für WinUI 3: https://docs.microsoft.com/windows/apps/winui/winui3

[7] WinUI Roadmap: https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md