GUI-Frameworks für .NET – Teil 2: WPF und WinUI 3

In der Artikelserie geht es diesmal um die neueren GUI-Frameworks Windows Presentation Foundation und Windows UI Library 3.

vorlesen Druckansicht 11 Kommentare lesen
.NET-Plakette

(Bild: erzeugt mit KI durch iX)

Lesezeit: 20 Min.
Von
  • Dr. Holger Schwichtenberg
Inhaltsverzeichnis
close notice

This article is also available in English. It was translated with technical assistance and editorially reviewed before publication.

Nachdem der erste Teil dieser Serie Windows Forms behandelt hat, geht es nun um Windows Presentation Foundation (WPF) und Windows UI Library 3 (WinUI 3). Beide GUI-Frameworks basieren auf XAML (eXtensible Application Markup Language). XAML ist eine XML-basierte Markup-Sprache. Sie vereint die Strukturbeschreibung, Inhalte, Layout, Design, Transformationen und Animationen zu einer einzigen Sprache – anders als bei Webseiten, wo diese Kompetenzen zwischen HTML und CSS aufgeteilt, teils aber auch vermischt sind (und in einigen Fällen auch JavaScript benötigt wird, um zu gleichen Ergebnissen wie in XAML zu gelangen).

Dr. Holger Schwichtenberg
Dr. Holger Schwichtenberg

Dr. Holger Schwichtenberg hat Fachbücher zu .NET 10.0, C# 14.0, Blazor 10.0 und Entity Framework Core 10.0 veröffentlicht. Er arbeitet als Berater und Trainer bei www.IT-Visions.de.

Qual der Wahl: GUI-Frameworks für .NET

XAML ist eine XML-basierte Sprache, mit der einzelne .NET-Objekte und ganze Objektbäume in XML-Form ausdrückbar sind. Innerhalb von WPF wird dies zur Beschreibung von Oberflächenelementen wie <TextBlock>, <TextBox>, <Button>, <ListBox>, <ToolTip>, <Line>, <Polygon>, <MediaElement> und vielen mehr verwendet. Elemente sind Teile von Containern, die die Anordnung bestimmen, etwa <Canvas>, <Grid>, <DockPanel> und <Frame>.

Zu jedem XAML-Element existiert eine gleichnamige .NET-Klasse. XAML-Oberflächen können daher auch codebasiert erstellt werden, was aber eher selten ist und typischerweise nur in metadatenbasierten Anwendungen erfolgt, deren grafische Oberflächen erst dynamisch zur Laufzeit entstehen.

Heise-Konferenz: betterCode() .NET 10.0 am 18. November
Online-Konferenz betterCode() 10.0 am 18. November 2025

(Bild: coffeemill/123rf.com)

Das nächste LTS-Release steht an: Auf der Online-Konferenz betterCode() .NET 10.0 am 18. November 2025 – ausgerichtet von iX und dpunkt.verlag in Kooperation mit IT-visions.de – präsentieren der Autor dieses Artikels, Dr. Holger Schwichtenberg, und weitere Experten die wichtigsten Neuerungen. Dazu zählen die Updates im .NET 10.0 SDK sowie in C# 14.0, ASP.NET Core 10.0, Blazor 10.0, Windows Forms 10.0, WPF 10.0, WinUI 3, .NET MAUI 10.0 und die Integration von Künstlicher Intelligenz in .NET-Anwendungen.

Das Programm ist noch nicht veröffentlicht – bis dahin sind vergünstigte Blind-Bird-Tickets bereits im Online-Shop erhältlich. Das Vorjahresprogramm lässt sich im Archiv einsehen.

Die Windows Presentation Foundation (WPF, früherer Codename: Avalon) wurde in .NET Framework 3.0 im Jahr 2006 eingeführt und ist genau wie Windows Forms seit .NET Core 3.0 auch im modernen .NET verfügbar. Die .NET-Klassen zu den XAML-Steuerelementen in WPF liegen in der .NET-Klassenbibliothek im Namensraum System.Windows in den .NET-Assemblies PresentationCore.dll und PresentationFramework.dll.

Genau wie bei Windows Forms gibt es für WPF einen mächtigen WYSIWYG-Designer innerhalb von Visual Studio, der XAML-Code erzeugt. Viele WPF-Entwicklerinnen und -Entwickler bevorzugen die direkte Eingabe von XAML-Tags anstelle der Verwendung des Designers, weil sie dort per Tastatur produktiver sind als mit der Maus.

Die Lokalisierung von Anwendungen ist im WPF-Designer nicht so einfach wie bei Windows Forms. Neben dem Visual-Studio-Designer gibt es mit Blend ein spezielles Designerwerkzeug für WPF, das ab 2007 zunächst ein eigenständiges Programm war. Es hieß erst Expression Interactive Designer, dann Microsoft Expression Blend. Seit 2012 gibt es nur noch das in Visual Studio integrierte Blend (Microsoft Blend for Visual Studio).

Im Unterschied zu Windows Forms bietet WPF beim Debugging eine Live-Ansicht in der Entwicklungsumgebung und Hot Reloading, das heißt, Entwicklerinnen und Entwickler können beim Debugging die Oberfläche ändern und die Änderungen direkt in der laufenden Anwendung sehen, ohne die Anwendung beenden und neu starten zu müssen.

WPF erlaubt eine gute Trennung zwischen Oberflächenbeschreibung und Programmcode. Dafür hat sich eine modifizierte Version des Model-View-Controller-Pattern unter dem Namen Model-View-ViewModel (MVVM) etabliert. Wie zum Thema Windows Forms erwähnt, ist MVVM aber inzwischen auch in Windows Forms an einigen Stellen möglich. Dennoch bleiben die Möglichkeiten der Datenbindung in WPF denen in Windows Forms klar überlegen; es gibt in WPF eine deklarative Datenbindung für alle Eigenschaften jedes Steuerelements inklusive erweiterbaren Typ-Konvertern. Binden kann man an andere GUI-Elemente oder beliebige Datenquellen in Form von typisierten .NET-Objekten.

Videos by heise

Zudem ist in WPF die Anpassung des Designs einer Benutzeroberfläche deutlich einfacher als in Windows Forms, denn alle XAML-Steuerelemente lassen sich miteinander kombinieren (zum Beispiel kann ein Kontrollkästchen Teil eines Auswahlfeldes sein oder es kann ein Video-Hintergrund in einem Eingabefeld laufen), durch Styles anpassen und durch Control Templates auch grundsätzlich umgestalten. Über sogenannte Resource Dictionaries lassen sich Styles und Control Templates zentral definieren, um sie dann für mehrere WPF-Steuerelemente zu nutzen. Dadurch können Entwicklerinnen und Entwickler beispielsweise sicherstellen, dass alle TextBox-Elemente eines Fensters oder der gesamten WPF-Anwendung exakt gleich aussehen.

Zudem lässt sich Responsive Design, also das Anpassen einer Benutzeroberfläche an verschiedene Bildschirmgrößen und -auflösungen, leichter mit WPF als mit Windows Forms umsetzen. WPF verwendet vektorbasiertes Rendering. Daher lassen sich sehr einfach Anwendungen mit Vergrößerungsfunktionen (Zoom) erstellen beziehungsweise Anwendungen, die auf unterschiedlichen Monitorgrößen nutzbar sind. Allerdings bietet WPF keine SVG-Integration. Dafür braucht man ein Community-Projekt namens SharpVectors. WPF bietet eine integrierte Unterstützung für Transformationen und Animation von beliebigen Oberflächenelementen. Die WPF-Eingabesteuerelemente erlauben Eingaben per Sprache und Stift.

Seit .NET 9.0 liefert Microsoft ein Resource Dictionary, mit dem WPF-Anwendungen das Fluent Design von Windows 11 annehmen können (auch unter Windows 10). WPF-Anwendungen haben ein moderneres Look and Feel als Windows-Forms-Anwendungen; Fluent Design vergrößert den optischen Vorsprung von WPF weiter. Mit WPF hat Microsoft also die Themen Design und User Experience auf Windows deutlich vorangetrieben.

Wie in Abbildung 1 zu sehen ist, wirkt die Fluent-Design-Oberfläche (Mitte und rechts) wesentlich moderner als das klassische WPF-Design (links). Allerdings werden durch veränderte Standardgrößen nun Anpassungen an der Oberfläche notwendig, denn es ist nicht mehr der gesamte Text lesbar und die Liste hat einen viel zu großen Abstand. In der rechten Fassung wurden die Größen und Abstände dann manuell korrigiert.

Klassisches WPF-Design (links) versus WPF im Fluent Design (Mitte und rechts)(Abb. 1).

(Bild: Holger Schwichtenberg)

WPF rendert hardwarebeschleunigt auf Basis von Microsoft-DirectX-Technik (DirectX-Version 9; im modernen .NET kommt in WPF teilweise DirectX 11 zum Einsatz). Dennoch sind WPF-Anwendungen oft nicht performanter als ein Windows-Forms-Pendant, das direkt auf den Betriebssystem-APIs aufsetzt; fallweise ist WPF sogar träger.

WPF und XAML wurden von Microsoft nicht nur als GUI-Framework für klassische Windows-Geschäftsanwendungen erschaffen, sondern erlauben auch Multimedia- und 3D-Anwendungen, die Darstellung von Dokumenten (Open XML Paper Specification – XPS) sowie browserbasierte Anwendungen (XAML Browser Application – XBAP). Für Dokumente und den Browser hat sich WPF aber nicht durchgesetzt. XBAP gibt es im modernen .NET nicht mehr. Der Namensraum System.Windows.Xps ist aber noch vorhanden. Da es neben dem Wegfall von XBAP kaum Unterschiede zwischen WPF im klassischen .NET Framework und modernen .NET gibt, erfordert eine Migration von WPF-Oberflächen auf die neueste Version nur geringen Aufwand.

WPF liefert einige Steuerelemente für viele Fälle mit. Einen Überblick über die mitgelieferten Steuerelemente findet man in der WPF-Anwendung "WPF Gallery", die es im Windows Store gibt (siehe Abbildung 2). Wie bei Windows Forms gilt auch hier, dass man höherwertige Steuerelemente bei Drittanbietern zukaufen muss (siehe Tabelle 1). Ein Ribbon-Steuerelement ist aber bei WPF im Kern dabei, in der Klasse System.Windows.Controls.Ribbon.

WPF Gallery App aus dem Windows Store (Abb. 2)

(Bild: Holger Schwichtenberg)

Hersteller Produktname
Telerik UI for WPF
DevExpress WPF Component Subscription
Infragistics Ultimate UI for WPF
Syncfusion WPF controls
Mescius (vormals GrapeCity) ComponentOne WPF UI Controls
Actipro Software WPF Controls
Xceed Toolkit plus for WPF
Text Control TX Text Control .NET
Lepo/Community WPF UI

Tabelle 1: Ausgewählte GUI-Komponentenanbieter für WPF

Aufgrund der Mächtigkeit von WPF ist der Lernaufwand für WPF für Einsteiger größer als bei Windows Forms.

WPF hat in den letzten modernen .NET-Versionen wenig Neuerungen erhalten, deutlich weniger als Windows Forms. Meist lagen die Verbesserungen nur in den Bereichen Performance und Accessibility. Seit .NET 6.0 laufen WPF-Anwendungen (wie Windows Forms) auch auf Windows-ARM64-Systemen. Erst in .NET 8.0 hat Microsoft ein großes Problem von WPF gelöst, das all die Jahre lang den Einsatz von WPF-Anwendungen für Remote Desktops erschwerte: Bisher war Software-Rendering (CPU) der Standard bei Verbindungen mit dem Remote Desktop Protocol (RDP). Erst ab .NET 8.0 lässt sich über einen Konfigurationseintrag das GPU-basierte Hardware-Rendering einschalten. In .NET 8.0 hat Microsoft zudem die Klasse OpenFolderDialog ergänzt. Eine dritte größere Neuerung für WPF gab es in .NET 9.0, das am 12. November 2024 mit dem Fluent Design (oben bereits erwähnt) erschien, einschließlich Unterstützung für Dark Mode von Windows 10 und 11.

WPF und die Vorgängertechniken lassen sich übrigens integrieren: In WPF ist Interoperabilität zu Win32- und Windows-Forms-Benutzerschnittstellen eingebaut, das heißt WPF-Anwendungen können Windows-Forms- oder Win32-Steuerelemente enthalten. Umgekehrt ist ein WPF-Steuerelement in Win32- oder Windows-Forms-Fenster einbindbar. Bei der Installation gibt es die gleichen Möglichkeiten wie bei Windows Forms.

Genauso wie Windows Forms wird auch WPF in den Medien immer wieder totgesagt, etwa im Magazin dotnetpro, Ausgabe 5/2023:

  • "Jetzt, im Jahr 2023, müssen wir akzeptieren: WPF steht offenbar auf dem Abstellgleis."
  • "Den Sargnagel hat dann noch ein Live-Stream von Microsoft im Februar eingeschlagen: Die Entwicklung und Betreuung von WPF wurde von Microsoft an das Microsoft‘s India Developer Center ausgelagert, das sich mithilfe von zwei bis drei Entwickelnden des Themas annehmen soll."
  • "Sind wir aber ehrlich: WPF ist tot! Es lebt in dem aktuellen Stand sicherlich noch mehr als zehn Jahre weiter, wird sich aber auch nicht mehr groß verändern."

Ich meine jedoch, dass "tot" hier nicht der passende Ausdruck ist. Alles, was noch mit aktuellen .NET-Versionen ausgeliefert wird beziehungsweise Bugfixes erhält, lebt. Gerade die Theming-Neuerungen in WPF in .NET 9.0 haben gezeigt, dass auch darüber hinaus noch Leben in WPF steckt.

WPF ist etabliert und bewährt. Daher kommt WPF in vielen .NET-Anwendungen zum Einsatz und es gibt auch immer wieder neue Anwendungen mit WPF. Jedoch steigen kaum noch Entwicklungsteams von Windows Forms auf WPF um. Denn erstens können Entwicklerinnen und Entwickler mit Komponentenbibliotheken von Drittanbietern vieles auch in Windows Forms erreichen und zweitens ähnelt die Zukunftsperspektive von WPF der von Windows Forms, das heißt, es gibt nur kleinere Verbesserungen, aber keine großen Innovationen mehr.