© Sol Slav/Shutterstock.com
Teil 1: Desktop-Apps mit WinUI 3

Modernes WinUI für den Windows-Desktop


Mit Windows 10 hat Microsoft die Universal-Windows-Platform-(UWP-)Apps eingeführt. Diese Apps lassen sich wie WPF-Anwendungen mit XAML und C# entwickeln. Dabei ist das genutzte UI Framework Teil von Windows 10. Und genau dieses UI Framework wird von Windows 10 entkoppelt und als WinUI 3.0 bereitgestellt. Dieser Artikel ist der Start einer Serie zu WinUI. Er gibt einen groben Überblick der Desktop-UI-Frameworks von Windows Forms über die WPF bis hin zu WinUI und geht dabei näher auf WinUI ein.

Hat man sich heute zum Entwickeln einer Windows-Desktopanwendung mit C# entschieden, so steht man vor der Qual der Wahl: Windows Forms, WPF, UWP, WinUI? Manche Entwickler schwelgen gerne in Erinnerungen und denken zurück an das Jahr 2002. Damals kam die erste Version des .NET Frameworks heraus. Zum Entwickeln einer Windows-Desktopanwendung mit C# musste man nicht lange über das zu verwendende UI Framework nachdenken, denn es gab nur eine Antwort: Windows Forms.

Windows Forms

Windows Forms (WinForms) ist das UI Framework, das seit dem .NET Framework 1.0 zur Verfügung steht. Es erlaubt eine recht produktive Entwicklung, da es in Visual Studio eine sehr gute Designer-Unterstützung bietet. Controls lassen sich aus der Toolbox auf die Oberfläche ziehen und anordnen. Ruckzuck ist eine Oberfläche fertiggestellt. Diese extrem hohe Produktivität macht Windows Forms auch heute noch zu einem sehr beliebten UI Framework.

Unter der Haube baut Windows Forms auf dem Graphical Device Interface (GDI+) auf, das Teil der Win32-Schnittstelle von Windows ist. Darüber zeichnet Windows Forms die Ausgabe auf den Bildschirm.

Der große Nachteil von Windows Forms ist, dass sich die Benutzeroberfläche nur in C# definieren lässt. Seit dem 2005 erschienenen .NET Framework 2.0 und den damit eingeführten partiellen Klassendefinitionen wird der UI-spezifische, vom Designer generierte Code in einer eigenen designer.cs-Datei erstellt. Vor dem .NET Framework 2.0 wurde der generierte Code mit einer #region-Direktive versteckt. Doch Wehe dem Entwickler, der in der designer.cs-Datei irgendetwas ändert: Der Entwickler wird zum Elefanten im Porzellanladen. Obwohl der manuell editierte C#-Code in der designer.cs-Datei an und für sich gültig ist und kompilieren würde, muss er eine bestimmte Struktur aufweisen, sonst lässt sich das Projekt nicht mehr bauen. Es kommt zu seltsamen Compile-Fehlern. Somit ist die goldene Regel, die designer.cs-Datei niemals von Hand zu editieren, sondern dazu immer den Windows Forms Designer in Visual Studio zu benutzen. Dieses ganze Problem ist darauf zurückzuführen, dass es bei Windows Forms keine klare Trennung zwischen der Benutzeroberfläche und der eigentlichen Logik gibt. Alles wird in Windows Forms komplett in C# erstellt.

Insbesondere im Web hat sich mit HTML und JavaScript längst die Trennung von UI und UI-Logik bewährt. Markup-Sprachen wie HTML eignen sich sehr gut zum Definieren von Benutzeroberflächen. Die fehlende Markup-Sprache war mit ein Grund, warum 2006 als Teil des .NET Frameworks 3.0 ein weiteres, moderneres Programmiermodell für Windows-Desktopanwendungen herauskam, die Windows Presentation Foundation (WPF).

Windows Presentation Foundation

Bei manchen Programmierern, die die technische Entwicklung im Hause Microsoft nicht mitverfolgt hatten, sorgte die Nachricht von einem weiteren Programmiermodell für Benutzeroberflächen als Teil des .NET Frameworks 3.0 zuerst für etwas Verwirrung. Schließlich enthielt das .NET Framework seit Version 1.0 mit Windows Forms ein bewährtes Programmiermodell zur Entwicklung von Windows-Desktopanwendungen. Insbesondere im .NET Framework 2.0 wurde Windows Forms stark verbessert und erfreute sich großer Beliebtheit. Viele Entwickler stellten sich demzufolge die Frage, was das neue Programmiermodell für Vorteile bringen würde und warum sie in Zukunft die WPF anstelle von Windows Forms einsetzen sollten.

Eine der bedeutendsten Änderungen war die neue, XML-basierte Beschreibungssprache Extensible Application Markup Language (XAML, sprich „Semmel“). XAML wird in der WPF zur deklarativen Beschreibung von Benutzeroberflächen eingesetzt. Benutzeroberflächen lassen sich mit der WPF zwar auch weiterhin in C# erstellen, XAML bietet aber eine saubere Trennung zwischen UI und UI-Logik.

Auch setzt die WPF nicht mehr auf GDI+, sondern kapselt zur grafischen Ausgabe DirectX. DirectX ist eine Bibliothek, die den Zugriff auf die Hardware erlaubt. Dadurch kann die WPF zum Zeichnen der Benutzeroberfläche im Gegensatz zu Windows Forms den grafischen Prozessor (GPU) anstatt dem Hauptprozessor (CPU) nutzen, womit sich visuell alle möglichen Szenarien umsetzen lassen.

Während also vieles in der WPF deutlich besser als in Windows Forms gelöst ist, werden immer noch zahlreiche neue Anwendungen mit Windows Forms erstellt. Der Grund dafür ist wohl hauptsächlich die Einstiegshürde bei WPF. Die ist um einiges höher als die bei Windows Forms. Neben XAML müssen Entwickler Dinge wie Layout, Dependency Properties, Routed Events, Data Binding sowie Styles und Templates verstehen. Dazu kommen UI-Patterns wie beispielsweise das in XAML-Anwendungen weit verbreitete Model-View-ViewModel-Pattern (MVVM).

Das heißt, dass sich heute sowohl Windows Forms als auch WPF großer Beliebtheit erfreuen, und es gibt zahlreiche damit entwickelte Anwendungen. Auch neue Anwendungen werden insbesondere im Enterprise-Umfeld mit Windows Forms oder WPF entwickelt. Es sind zwei sehr verbreitete UI Frameworks. Aus diesem Grund hat Microsoft beide UI Frameworks auch auf .NET Core portiert, das die Zukunft von .NET darstellt.

Vom .NET Framework zu .NET Core

Heute sind sowohl Windows Forms als auch die WPF Teil des .NET Frameworks 4.8 und seit .NET Core 3.0 auch Teil von .NET Core. Im Zuge der Portierung auf .NET Core hat Microsoft sowohl den Quellcode von Windows Forms [1] als auch ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang