Wie Sie zwischen WinForms, WPF und WinUI wählen - Entscheidungstabelle für die Praxis

Zielgruppe: Entwickler, die Windows-Desktopanwendungen mit C# / .NET erstellen, sowie Personen, die über die technische Ausrichtung entscheiden. Voraussetzung: Es wird das aktuelle .NET (nicht .NET Framework) verwendet, und die Zielplattform ist ausschließlich Windows. Leseempfehlung: Wer nur die Kernaussage will, liest Kapitel 1 und 3; wer die Verlängerungsstrategie für eine bestehende App festlegen möchte, liest Kapitel 7; wer den letzten Ausschlag braucht, beginnt bei Kapitel 8.

Beim Bau einer Windows-Desktopanwendung mit C# / .NET ist es jedes Mal ein kleines, aber lästiges Kopfzerbrechen, welches der drei - WinForms, WPF oder WinUI - man wählen soll.

Gefährlich wird es bei einer vagen Auswahl wie:

• WinUI, weil es am neuesten ist
• WinForms, weil man es am besten kennt
• WPF, weil es sich irgendwie nach der Mitte anfühlt

In der Praxis sind die Kriterien, auf die es ankommt, etwas klarer.

• Neuentwicklung oder Fortführung eines Altbestands?
• Sind die Bildschirme überwiegend Eingabeformulare, oder wird Ausdruckskraft benötigt?
• Ist eine moderne, für Windows typische UI selbst der Produktwert?
• Wie werden Verteilung, Aktualisierung und der Betrieb im Unternehmen gehandhabt?
• Hat das Team eine Designer-Kultur oder eine XAML-/MVVM-Kultur?

In diesem Artikel ordnen wir das Ganze übersichtlich in einer einzigen Entscheidungstabelle. In diesem Artikel bezeichnet WinUI hauptsächlich WinUI 3 + das Windows App SDK. ¹²

Außerdem sind alle drei ausschließlich für Windows bestimmt. Wenn auch macOS / Linux ins Blickfeld rücken, ist die Fragestellung von Grund auf eine andere. ³⁴¹

1. Zunächst die Kernaussage (kurz gefasst)

Vorab, ziemlich unverblümt, aber praxistauglich formuliert:

• Ist eine bestehende WinForms-Anwendung groß, prüfen Sie zuerst grundsätzlich die Fortführung mit WinForms
• Ist eine bestehende WPF-Anwendung groß, prüfen Sie zuerst grundsätzlich die Fortführung mit WPF
• Für ein neues, kleines bis mittleres internes Tool, das auf Standardsteuerelementen und Eingabemasken basiert und schnell entstehen soll, ist WinForms immer noch ziemlich stark ³⁵
• Für eine neue, mittelgroße bis große Geschäftsanwendung mit vielen Bildschirmen, bei der Sie Data Binding, Styles, Templates, Commands und MVVM richtig nutzen möchten, ist WPF meistens die sicherste Wahl ⁴⁶⁷
• Für ein neues, ausschließlich für Windows bestimmtes Produkt, bei dem eine moderne Windows-UI, Fluent und das aktuelle Windows-Erlebnis unmittelbar den Produktwert ausmachen, ist WinUI eine starke Option ¹²
• Wenn Sie lediglich die neuesten Windows-APIs nutzen möchten, ist WinUI nicht zwingend erforderlich. Auch WPF / WinForms können Funktionen des Windows App SDK übernehmen ²⁸⁹¹⁰
• Sich auf die Annahme zu verlassen, „man kann WinUI später Stück für Stück einbauen”, ist etwas riskant. Eine schrittweise Migration ist unordentlicher, als es klingt ¹⁰¹¹

Kurz gesagt läuft es auf Folgendes hinaus:

1. Ist der Altbestand groß, zuerst dessen Linie erhalten
2. Bei Neuentwicklung mit schnell zu bauenden Standardformularen: WinForms
3. Bei einer neuen, langfristig wachsenden Windows-Geschäftsanwendung: WPF
4. Bei Neuentwicklung, wenn eine moderne Windows-UI selbst Anforderung ist: WinUI
5. Wenn Sie nur das Windows App SDK wollen, nicht gleich alles auf WinUI umstellen

Die Framework-Wahl ist gleichzeitig eine UI-technische Entscheidung wie auch eine Entscheidung über Verteilung, Betrieb, Lernkosten und Migrationskosten. Entscheiden Sie hier nur nach „neu versus alt”, rächt sich das später beim Verteilungsdesign und den Wartungskosten in den nachgelagerten Schritten.

2. Die drei Technologien in diesem Artikel

Zunächst gleichen wir die Begriffe etwas an. Die Abkürzungen, die im weiteren Verlauf immer wieder auftauchen, lösen wir hier auf.

WinForms wird auch auf Microsoft Learn als Framework beschrieben, das Steuerelemente, Grafik, Data Binding und Benutzereingabe bereitstellt und Apps mit dem Drag-&-Drop-Designer von Visual Studio leicht erstellen lässt. ³

WPF ist ein UI-Framework mit hoher Ausdruckskraft, das auflösungsunabhängiges, vektorbasiertes Rendering, XAML, Data Binding, Styles / Templates, 2D / 3D und Animationen umfasst. ⁴

WinUI ist Teil des Windows App SDK - ein UI-Framework für das heutige Windows, das auf hohem DPI, moderner Eingabe, flüssigen Animationen und einem Fluent-artigen Erlebnis aufbaut. ¹² Auch data binding / MVVM sind ganz normal vorgesehen. ¹²

Wichtig ist hier: Das Windows App SDK und WinUI sind nicht dasselbe. WinUI ist der UI-Framework-Teil des Windows App SDK, aber das Windows App SDK selbst lässt sich auch bestehenden WPF-/WinForms-/Win32-Anwendungen hinzufügen. ²¹⁰

Deshalb sind

• WinUI verwenden
• Funktionen des Windows App SDK verwenden

zwei ähnlich klingende, aber getrennte Entscheidungen. Bleiben diese beiden vermischt, werden „ob die UI migriert werden soll” und „ob Funktionen hinzugefügt werden sollen” als dieselbe Frage behandelt, und es fällt schwer, zu einem Ergebnis zu kommen.

3. Die Entscheidungstabelle auf einen Blick

Zunächst die Tabelle, die in der Praxis am nützlichsten ist.

Diese Tabelle reicht meist schon aus, aber zwei Punkte, bei denen man oft ins Grübeln kommt, bleiben.

1. Bei einer neuen Windows-Geschäftsanwendung: eher WinForms oder eher WPF?
2. Bestehendes WPF / WinForms ist da - sollte man zu WinUI wechseln?

Diese beiden Punkte lassen sich leichter beurteilen, wenn man die folgende Vergleichstabelle heranzieht.

4. Vergleichstabelle nach Gesichtspunkten

Dies ist keine offizielle Rangliste, sondern ein stark praxisorientierter Vergleich.

Der Trick beim Lesen ist nicht „was ist am stärksten”, sondern „was verursacht am wenigsten Reibung”.

Zum Beispiel bei:

• internen Konfigurationswerkzeugen
• Einstellungsbildschirmen für Geräte
• Listen, Details, Suche, Einstellungen, Buttons
• wenn betriebliche Stabilität und Überarbeitungsgeschwindigkeit wichtiger sind als das Aussehen

ist WinForms nach wie vor durchaus vernünftig.

Umgekehrt, bei:

• vielen Bildschirmen
• häufigem Wechsel von Anzeigezuständen
• dem Wunsch, View und Logik zu trennen
• Datenänderungen, die sich natürlich in die UI einspeisen sollen
• dem Wunsch, die UI über Styles / Templates zu steuern

zahlt sich WPF gut aus. ⁶⁷

Und bei:

• einem Erscheinungsbild, das an Windows 11 angelehnt sein soll
• dem Wunsch, Fluent wirklich zu nutzen
• hohem DPI, Touch und modernen Fenster-APIs als Voraussetzung
• einem neuen, ausschließlich für Windows bestimmten Produkt, bei dem auch der Eindruck der UI wichtig ist

liegt WinUI nahe. ¹²

4.1 Den „Unterschied in der Ausdruckskraft” anhand minimalen Codes betrachten

Die Zeile „Verträglichkeit mit Data Binding / MVVM” in der obigen Tabelle ist in Worten allein schwer zu greifen. Wir stellen deshalb anhand von minimalem Code gegenüber, was sich ändert, wenn man denselben Bildschirm in WinForms und in WPF schreibt.

Gebaut wird ein Bildschirm mit nur „einem Textfeld und einem Speichern-Button”.

WinForms: Der Designer erzeugt *.Designer.cs, und im Event-Handler werden die Werte aus dem Bildschirm ausgelesen.

// MainForm.Designer.cs — Wird vom Designer erzeugt. Hier schreibt man nicht von Hand
private System.Windows.Forms.TextBox nameTextBox;
private System.Windows.Forms.Button saveButton;

private void InitializeComponent()
{
    this.nameTextBox = new System.Windows.Forms.TextBox();
    this.saveButton = new System.Windows.Forms.Button();
    this.SuspendLayout();

    this.nameTextBox.Location = new System.Drawing.Point(12, 12);
    this.nameTextBox.Size = new System.Drawing.Size(200, 23);

    this.saveButton.Location = new System.Drawing.Point(218, 12);
    this.saveButton.Size = new System.Drawing.Size(75, 23);
    this.saveButton.Text = "Speichern";
    this.saveButton.Click += new System.EventHandler(this.SaveButton_Click);

    this.Controls.Add(this.nameTextBox);
    this.Controls.Add(this.saveButton);
    this.ResumeLayout(false);
}

// MainForm.cs — Das ist die Seite, die von Hand geschrieben wird
public partial class MainForm : Form
{
    private readonly EditorService _service;

    public MainForm(EditorService service)
    {
        _service = service;
        InitializeComponent();
    }

    private void SaveButton_Click(object sender, EventArgs e)
    {
        // Wert direkt aus dem UI-Steuerelement auslesen und übergeben
        _service.Save(this.nameTextBox.Text);
    }
}

WPF: Im XAML wird nur festgelegt, „womit etwas verbunden ist”; das Auslesen und Setzen der Werte übernimmt das Binding.

<!-- MainWindow.xaml -->
<Window x:Class="MyApp.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="Bearbeiten" Width="360" Height="120">
    <StackPanel Orientation="Horizontal" Margin="12">
        <TextBox Width="200"
                 Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />
        <Button Width="75" Margin="6,0,0,0" Content="Speichern"
                Command="{Binding SaveCommand}" />
    </StackPanel>
</Window>

// MainWindow.xaml.cs — Vergisst man, DataContext zu setzen, passiert beim Binding gar nichts
public partial class MainWindow : Window
{
    public MainWindow(EditorService service)
    {
        InitializeComponent();
        this.DataContext = new MainViewModel(service);
    }
}

// MainViewModel.cs — Kennt den Bildschirm nicht. Hier lassen sich auch Unit-Tests schreiben
public sealed class MainViewModel : INotifyPropertyChanged
{
    private readonly EditorService _service;
    private string _name = string.Empty;

    public MainViewModel(EditorService service)
    {
        _service = service;
        SaveCommand = new RelayCommand(() => _service.Save(Name));
    }

    public string Name
    {
        get => _name;
        set
        {
            if (_name == value) return;
            _name = value;
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(Name)));
        }
    }

    public ICommand SaveCommand { get; }

    public event PropertyChangedEventHandler PropertyChanged;
}

RelayCommand ist eine kleine Klasse, die ICommand implementiert; sie ist auch in Bibliotheken wie CommunityToolkit.Mvvm enthalten und lässt sich mit rund 20 Zeilen auch selbst schreiben.

Zählt man nur die Zeilen, ist WPF umfangreicher. Der eigentliche Unterschied zeigt sich erst danach.

Bei 3 Bildschirmen ist WinForms schneller, bei 30 Bildschirmen ist WPF leichter zu handhaben - das ist die praktische Bedeutung dieses Unterschieds.

5. Für welche Projekte eignet sich was

5.1 WinForms

WinForms wird gerne unterschätzt, aber bei der schnellen Umsetzung von Geschäftsbildschirmen mit überwiegend Standardsteuerelementen ist es auch heute noch nicht zu unterschätzen. ³⁵

Besonders geeignet ist es zum Beispiel für Projekte wie:

• interne Konfigurationswerkzeuge
• Einstellungsbildschirme für Geräte, Messinstrumente oder Überwachungswerkzeuge
• Verwaltungsbildschirme, Suchbildschirme, Liste + Detail
• Projekte mit großem bestehendem WinForms-Bestand
• Teams mit einer starken Designer-Kultur beim Bildschirmaufbau

Die Stärke von WinForms ist, dass man ohne komplizierte Konzepte relativ schnell ein Ergebnis nahe am fertigen Produkt erhält. Formulare, Buttons, Labels, Textfelder, Datengitter. Ist das Ihr hauptsächliches Einsatzgebiet, ist WinForms durchaus konkurrenzfähig.

Allerdings sind auch die Schwächen klar erkennbar.

• Das Erscheinungsbild des gesamten Bildschirms stark vereinheitlichen wollen
• Die UI über Styles und Templates steuern wollen
• Komplexe Zustandsänderungen überwiegend über Data Binding abwickeln wollen
• Die Bildschirmlogik sauber trennen wollen

Hierfür sind WPF und WinUI unkomplizierter.

Baut man mit WinForms eine große Anwendung, wird daraus, sobald man nicht aufpasst, leicht ein Dschungel aus Event-Handlern. Entscheidet man sich für WinForms, ist es daher friedlicher, von Anfang an mindestens Folgendes festzulegen:

• Die Verantwortlichkeiten der Bildschirme klein halten
• Nach UserControl-Einheiten aufteilen
• Eine Grenze in der Art von Presenter / ViewModel im Blick behalten
• Geschäftslogik nicht direkt in Bildschirm-Events schreiben

Außerdem ist in der Praxis sehr wichtig: Nur weil man das Windows App SDK nutzen möchte, muss man WinForms nicht aufgeben. Es gibt auch offiziell einen Weg, bestehenden WinForms-Anwendungen Funktionen des Windows App SDK hinzuzufügen. ⁹¹⁰

Das heißt, bei WinForms ist folgende Wahl möglich:

• Die UI unverändert lassen
• Nur die benötigten Windows-Funktionen modernisieren

Das ist ein realistischer Kompromiss.

5.2 WPF

Betrachtet man WPF als .NET-UI für den Windows-Desktop, ist es der Kern mit der besten Balance. ⁴

Die Stärken sind eindeutig.

• Bildschirme lassen sich deklarativ in XAML schreiben
• Data Binding ist stark
• Styles / Templates stehen zur Verfügung
• Commands stehen zur Verfügung
• View und Logik lassen sich leicht trennen
• Mittelgroße bis große Bildschirmanzahlen lassen sich gut strukturieren

Auch in der offiziellen WPF-Dokumentation wird Data Binding als zentrales WPF-Feature beschrieben, und Commands werden als Mechanismus dargestellt, der Eingabe und Ausführungslogik trennt. ⁶⁷

Es eignet sich also zum Beispiel für Projekte wie:

• Geschäftsanwendungen mit vielen Bildschirmen
• viele Listen, Details, Bearbeitung, Suche, Statusanzeigen
• Windows-Anwendungen, die von mehreren Personen langfristig gewartet werden
• den Wunsch, View und Logik zu trennen
• den Wunsch, Aussehen und Verhalten für künftige Überarbeitungen getrennt zu halten
• Bildschirme, die in WinForms schnell schwerfällig würden

Bei Unklarheit über eine neue, ausschließlich für Windows bestimmte Geschäftsanwendung ist WPF auch heute noch der sichere erste Kandidat. Es mit „WPF ist alt, also nein” abzuschneiden, ist etwas voreilig.

Im Gegenteil: Wenn

• bereits WPF-Bestand vorhanden ist
• bereits XAML-/MVVM-Erfahrung vorhanden ist
• Fluent nicht die absolute Priorität hat
• aber die UI sauberer gestaltet sein soll als mit WinForms

dann ist es durchaus üblich, dass WPF die schlüssigste Wahl ist.

Natürlich hat auch WPF seine Eigenheiten.

• Zu verschachteltes XAML wird schwer lesbar
• Zu viele eigene Steuerelemente und Templates machen die Wartung schwer
• Zu starkes Setzen auf „alles per Binding lösen” macht den Ablauf paradoxerweise schwerer nachvollziehbar

Das gibt es tatsächlich, aber es liegt weniger daran, dass WPF schlecht ist, sondern eher daran, dass ein ausdrucksstarkes Werkzeug bei unbedachtem Einsatz auch entsprechend zurückschlägt.

Auch bei WPF lassen sich Teile des Windows App SDK hinzufügen. Das heißt, es gibt einen Weg, die Windows-Funktionen zu modernisieren, während man bei WPF bleibt. ⁸¹⁰

Deshalb gewinnt in der Praxis häufiger der Ansatz,

• WPF auf das aktuelle .NET auszurichten
• nur die benötigten Windows-Funktionen über das Windows App SDK hinzuzufügen
• die Architektur ausgehend von großen neuen Funktionen aufzuräumen

gegenüber der Alternative,

• WPF komplett zu verwerfen und vollständig zu WinUI zu migrieren.

5.3 WinUI

WinUI ist die moderne erste Wahl, wenn eine neue, ausschließlich für Windows bestimmte Anwendung entsteht. ¹²

Offiziell wird es positioniert als:

• optimiert für aktuelle Hardware und Eingabemethoden
• hohes DPI
• flüssige Animationen
• Teil des Windows App SDK

¹

Es eignet sich also für Projekte wie:

• ein neues, ausschließlich für Windows bestimmtes Produkt
• bei dem der Eindruck und das Erlebnis der UI selbst wichtig sind
• den Wunsch, Fluent unmittelbar zu nutzen
• den Wunsch, sich am aktuellen Stand von Windows 11 zu orientieren
• neue Fenster-APIs und das aktuelle Windows-Erlebnis als Voraussetzung

Projekte, bei denen es einen echten Grund gibt, WinUI zu wählen, sind meist keine Projekte, bei denen es nur „neu aussehen” soll, sondern solche, bei denen man „das aktuelle Windows-Erlebnis in das Produkt übernehmen” möchte.

Es gibt jedoch auch Punkte, die zu beachten sind.

5.3.1 WinUI ist nicht „einfach ein neueres WPF”

Da es XAML verwendet, wirkt es zwar ähnlich, aber

• die zugrunde liegenden APIs
• die Steuerelemente
• der Projektaufbau
• das Deployment-/Packaging-Konzept
• der Umgang mit dem Windows App SDK

unterscheiden sich.

Das heißt, es als unkomplizierten Ersatz für WPF zu betrachten, ist etwas riskant.

5.3.2 Entscheidet man sich für WinUI, rückt die Verteilung in den Vordergrund

WinUI-3-Anwendungen sind standardmäßig packaged. Das Windows App SDK selbst behandelt dagegen sowohl packaged als auch unpackaged. ¹³¹⁴²

Wichtig ist hier, frühzeitig zu klären:

• Wie wird verteilt?
• Wie wird die Runtime installiert?
• Wird package identity benötigt?
• Interne Verteilung, Store, MSIX oder der bestehende EXE-/MSI-Weg?

Das lieber früh entscheiden.

„Früh klären” allein sagt aber noch nicht, worauf genau man achten soll, daher hier die konkreten Inhalte der Prüfung.

Zunächst gibt es zwei Achsen, die zu entscheiden sind. ¹³¹⁵

• packaging: Ob die Anwendung eine package identity besitzt
• runtime: Ob das Windows App SDK framework-dependent genutzt oder self-contained mitgeliefert wird

Bei packaging gibt es drei Optionen. ¹³

Als Nächstes wird von der Funktionsseite her beurteilt, ob package identity benötigt wird. Funktionen, bei denen offiziell ausdrücklich festgehalten ist, dass sie „ohne package identity nicht funktionieren”, sind zum Beispiel: ¹³

• Hintergrundaufgaben
• Push-Benachrichtigungen (WNS)
• Freigabeziele
• Erweiterungen des Explorer-Kontextmenüs
• Zuordnung von Dateitypen und URI-Schemata
• Autostart-Aufgaben
• App Service
• Windows AI API

Für die Prüfung ist diese Reihenfolge praxistauglich.

1. Von den Anforderungen ausgehen. Ist geplant, eine der oben genannten Funktionen zu nutzen? Trifft auch nur eine zu, ist die packaged-Seite erforderlich.
2. Prüfen, ob das bestehende Installationsprogramm aufgegeben werden kann. Möchte man es nicht aufgeben, ist nicht die vollständige Migration zu MSIX die Antwort, sondern packaged mit externem Speicherort. Die bestehende Auslieferung der Binärdateien und der Aktualisierungsmechanismus bleiben unverändert, es wird lediglich die identity hinzugefügt. ¹³
3. Zur Laufzeit prüfen. Ob ein laufender Prozess eine identity hat, lässt sich mit GetCurrentPackageFullName feststellen. Fehlt die identity, wird APPMODEL_ERROR_NO_PACKAGE zurückgegeben. Erhält man umgekehrt beim Aufruf einer Windows-API E_ILLEGAL_METHOD_CALL oder APPMODEL_ERROR_NO_PACKAGE, ist das das Zeichen dafür, dass hier die Anforderung an package identity greift. ¹³
4. Auf dem Gerät prüfen. Installierte Pakete lassen sich mit dem PowerShell-Befehl Get-AppxPackage auflisten.
5. Zuletzt die Runtime festlegen. Soll per xcopy oder ZIP verteilt werden, ist self-contained der Standardweg; für eine Veröffentlichung im Store ist framework-dependent der Standardweg. ¹⁵

Auch bei WinForms / WPF ist Verteilung wichtig, aber bei WinUI tritt sie eher in den Vordergrund. Eine neue WinUI-3-Anwendung ist standardmäßig packaged, sodass man ohne bewusste Entscheidung automatisch auf den MSIX-Weg gerät. ¹³ Man dachte, man würde nur die UI festlegen, hatte aber eigentlich die Verteilungsstrategie festgelegt - das ist der etwas knifflige Punkt in dieser Welt.

5.3.3 „Bestehendes WPF / WinForms nach und nach mit WinUI mischen” erst klein testen

Hier neigen die Erwartungen dazu, sich aufzublähen. Allerdings steht auch im FAQ von Microsoft sinngemäß, dass WinUI sich oft nur einsetzen lässt, wenn man bereit ist, das UI-Framework vollständig zu migrieren. Zudem zeigt die offizielle Dokumentation zu XAML Islands zwar einen Weg zur Einbettung in bestehende Desktopanwendungen, aber die Release Notes zum Windows App SDK 1.4 halten fest, dass es derzeit hauptsächlich in C++-Anwendungen getestet wurde und keine bequemen Wrapper-Elemente für WPF / WinForms enthält. ¹⁰¹¹

Das heißt:

• „Eine schrittweise Migration scheint möglich”
• „Man könnte es Stück für Stück einbetten”

sind als Konzept attraktiv, sollten aber klein getestet werden, bevor sie zur Hauptstrategie eines Projekts werden.

WinUI ist dann am schlüssigsten, wenn man

• neu anfängt
• ein Erlebnis für ein ausschließlich für Windows bestimmtes Produkt gestaltet

Umgekehrt braucht es als Auffangbecken für einen vollständigen Ersatz von bestehendem WPF / WinForms Begründung und Verifikation.

6. Häufige Fehlentscheidungen

6.1 „WinUI, weil es am neuesten ist”

Das klingt einleuchtend, ist aber ziemlich riskant.

Den Grund für die Wahl einer neuen Technologie sollte man danach beurteilen, ob es einen Wert gibt, der sich nur mit dieser Technologie erreichen lässt.

• Ist das moderne Windows-Erlebnis der Produktwert?
• Möchte man Fluent unmittelbar nutzen?
• Handelt es sich um ein neues Produkt?
• Lassen sich die Voraussetzungen bei Verteilung / Betrieb akzeptieren?

Ist das alles mit Ja zu beantworten, ist WinUI eine starke Option. Lautet die Begründung dagegen nur „scheint zukunftssicher”, ist die Kostenrechtfertigung schwach.

6.2 „Man will das Windows App SDK nutzen, also muss es WinUI sein”

Das ist ein verbreitetes Missverständnis, und es stimmt nicht.

Das Windows App SDK lässt sich auch bestehendem WPF / WinForms hinzufügen. Auch das offizielle FAQ stellt klar, dass WPF-/MFC-/WinForms-Anwendungen Windows-App-SDK-APIs nutzen können, die nichts mit WinUI zu tun haben. ¹⁰⁸⁹

Zum Beispiel lassen sich Funktionen wie:

• App Lifecycle
• Windowing
• Toast Notifications

in manchen Fällen einbinden, während die aktuelle UI erhalten bleibt. ¹⁰

6.3 „WPF / WinForms sind bereits am Ende”

Auch hier sollte man nicht pauschal abschneiden.

Sowohl WinForms als auch WPF verfügen auf dem aktuellen .NET über durchgängige Dokumentation und Migrationspfade und werden auch offiziell als aktive Windows-Desktop-UIs behandelt. ³⁴

Als Entscheidungsgrundlage für die langfristige Wartung ist weniger „bleibt die Dokumentation erhalten” als vielmehr „kommen weiterhin neue Funktionen hinzu” der aussagekräftigere Indikator. Betrachtet man es unter diesem Gesichtspunkt, sieht die Lage bei allen drei so aus:

Für die langfristige Wartung lässt sich das also so lesen:

• WPF und WinForms sind nicht „eingefroren und sich selbst überlassen”, sondern erhalten mit jedem jährlichen .NET-Release neue Funktionen. Bei WinForms befinden sich die Vorzeigefunktionen jedoch teils noch in einem experimentellen Stadium, daher ist der Einführungszeitpunkt zu prüfen.
• Entscheidet man sich für WinUI, muss man die Support-Fristen von .NET und die des Windows App SDK getrennt verwalten. Bei langfristigen Projekten macht sich das unauffällig, aber spürbar bemerkbar.
• Egal wofür man sich entscheidet, es gibt keine Garantie, dass es „in 10 Jahren noch unverändert läuft”; daher ist es praxistauglicher, von vornherein festzulegen, bis zu welcher Version man mitzieht.

Besonders bei Geschäftsanwendungen wiegt Folgendes normalerweise schwerer als die Aktualität des UI-Frameworks:

• Altbestand
• Drittanbieter-Steuerelemente
• Bildschirmanzahl
• Berichte und Druck
• Gerätekopplung
• Verteilungsverfahren

6.4 „Dann kann man auch gleich alles neu schreiben”

Ein vollständiger Neuschrieb ist weniger eine Technologieentscheidung als eine unternehmerische Entscheidung.

Ist eine bestehende Anwendung vorhanden, sollte man zunächst Folgendes prüfen:

1. Was ist eigentlich das wirkliche Problem?
2. Ist es ein UI-Problem oder ein Architekturproblem?
3. Sind abhängige DLLs / COM / OCX / Berichte / Verteilung nicht die eigentliche Last?
4. Lässt sich das Problem lösen, ohne die gesamte UI zu ändern?

Eine UI-Neufassung wirkt spektakulär, aber ihre Kosten sind es ebenfalls. Und selbst wenn das Erscheinungsbild neu ist, bleibt die umgebende Komplexität meist bestehen.

6.5 „Später lässt sich das mit XAML Islands schon lösen”

Diese Hoffnung ist verständlich. Aber es ist sicherer, sie von Anfang an nicht als Rettungsboot zu behandeln. ¹⁰¹¹

Bei einer schrittweisen Migration sollte man vorab im Kleinen prüfen:

• Welche Steuerelemente sollen eingebettet werden?
• Wie verhalten sich Fokus, Eingabe, DPI und Theming?
• Erweist sich diese Hosting-Konfiguration in der Praxis als stabil?

7. Betrachtungsweise, wenn eine bestehende Anwendung die Ausgangslage ist

Hier ist eine bestehende Anwendung wichtiger als eine neue.

7.1 Wenn bereits WinForms vorhanden ist

Bevor man voreilig zu WinUI springt, prüft man zunächst Folgendes.

• Lässt es sich auf das aktuelle .NET ausrichten?
• Ist eine 64-Bit-Umstellung nötig?
• Lassen sich async / await, Fehlerbehandlung, Einstellungen und Protokollierung aufräumen?
• Lässt sich die Wartbarkeit durch Bildschirmaufteilung oder UserControls verbessern?
• Lassen sich die benötigten Windows-Funktionen allein über das Windows App SDK hinzufügen?

Was wie ein WinForms-Problem aussieht, ist in Wirklichkeit nicht selten nur:

• Bildschirm und Logik sind vermischt
• die Thread-Grenzen sind unsauber
• Einstellungen / Dateien / COM / DB-Verantwortlichkeiten sind zusammengepfercht

In diesem Fall bleibt das Problem beim Umzug zu WinUI erhalten - es bekommt lediglich einen neuen Namen.

7.2 Wenn bereits WPF vorhanden ist

WPF lässt sich bei bestehendem Bestand gut weiternutzen.

• XAML-Bestand
• Binding
• Style / Template
• Command
• MVVM

Der Grund, diese aufzugeben, sollte ziemlich eindeutig sein.

Zum Beispiel, wenn:

• die Produkt-UI vollständig erneuert werden soll
• Fluent zur Hauptachse werden soll
• ein neues Modul als eigenständiges Produkt herausgelöst wird
• man sich als ausschließlich für Windows bestimmtes Produkt auf ein neues Erlebnis zubewegen möchte

dann ist das ein Grund, WinUI in Betracht zu ziehen. Aber nur „weil WPF alt ist” ist ein schwaches Argument.

7.3 Was wirklich schwer wiegt, liegt oft außerhalb der UI

In der Praxis liegt die eigentliche Last überraschend oft hier:

• ActiveX / OCX
• COM-Interop
• eigene Berichte
• Druck
• Excel-/Office-Anbindung
• native DLLs
• Verdrehungen zwischen 32-Bit und 64-Bit
• Installationsprogramm, Berechtigungen, Aktualisierung, Signierung

Nimmt man das auf die leichte Schulter, wird das Projekt als Ganzes nicht leichter, selbst wenn nur die UI aufgeräumt wird.

Bei der Migration einer bestehenden Anwendung ist es daher vorrangig, nicht nur das UI-Framework zu betrachten, sondern die Abhängigkeitsgrenzen insgesamt zu inventarisieren.

8. Die letzten 5 Fragen bei Unentschlossenheit

Ist man am Ende noch unentschlossen, geht man diese 5 Fragen der Reihe nach durch.

8.1 Ist der Altbestand groß?

• Groß → grundsätzlich die bestehende Linie beibehalten
• Klein / nicht vorhanden → zur Neuauswahl übergehen

8.2 Ist ein „für Windows typisches, modernes Erlebnis” für diese Anwendung zwingend erforderlich?

• Zwingend erforderlich → WinUI ist eine starke Option
• Nicht unbedingt → prüfen, ob WPF / WinForms ausreicht

8.3 Sind die Bildschirme überwiegend Standardformulare, oder ist XAML-artige Ausdruckskraft nötig?

• Überwiegend Standardformulare → WinForms
• Styles / Templates / Binding / MVVM sind wichtig → WPF

8.4 Geht es um eine vollständige UI-Erneuerung oder nur um zusätzliche Windows-Funktionen?

• Vollständige UI-Erneuerung → WinUI prüfen
• Nur zusätzliche Funktionen → zuerst aktuelles WPF / WinForms + Windows App SDK prüfen

8.5 Lassen sich Verteilung / Aktualisierung / Betrieb bereits im Vorfeld erklären?

• Noch unklar → bei WinUI frühzeitig Packaging / Deployment klären
• Man möchte stark auf dem bestehenden Betrieb aufsetzen → WPF / WinForms verursachen häufig weniger Reibung

Mit diesen 5 Fragen lässt sich die Auswahl deutlich eingrenzen. Zum Schluss noch einmal grob zusammengefasst:

• Schnell zu bauende interne Formulare → WinForms
• Eine langfristig wachsende Windows-Geschäftsanwendung → WPF
• Eine neue, moderne Windows-Produkt-UI → WinUI
• Bestehendes weiternutzen und nur die Windows-Funktionen modernisieren → aktuelles Framework + Windows App SDK

9. Zusammenfassung

Die Wahl zwischen WinForms, WPF und WinUI ist kein Spiel, bei dem man nach Alter sortiert und das Rechteste nimmt.

Zunächst sollte man diese 4 Punkte betrachten.

1. Wo liegt der Altbestand?
2. Sind die Bildschirme formularzentriert oder ausdrucksstark?
3. Ist eine für Windows typische, moderne UI eine Produktanforderung?
4. Wie werden Verteilung / Aktualisierung / Betrieb abgewickelt?

Sind diese 4 Punkte klar, ergibt sich die Richtung meist von selbst.

• Ist ein großer bestehender WinForms-Bestand vorhanden, zunächst WinForms fortführen
• Ist ein großer bestehender WPF-Bestand vorhanden, zunächst WPF fortführen
• Neu und überwiegend Standardformulare → WinForms
• Neu und eine mittelgroße bis große Windows-Geschäftsanwendung → WPF
• Neu und ein modernes Windows-Erlebnis selbst ist Anforderung → WinUI
• Will man nur das Windows App SDK, nicht gleich alles auf WinUI umstellen

Am meisten zu vermeiden sind diese 3 Dinge:

• verwerfen, weil es alt ist
• wählen, weil es neu ist
• anfangen mit der Haltung, es werde sich unterwegs schon klären

Der Windows-Desktop ist eine Welt, in der Altbestand, Verteilung, Betrieb und Abhängigkeiten schwerer wiegen als das Äußere. Bei der Wahl also eher auf möglichst wenig Reibung zu achten als auf den Glanz, ist meist der Weg, mit dem man gewinnt.

10. Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist der Unterschied zwischen WinUI 3 und WPF?

Beide verwenden XAML, aber WinUI ist nicht einfach „ein neueres WPF“. Die zugrunde liegenden APIs, die Steuerelemente, der Projektaufbau, das Deployment-/Packaging-Konzept und der Umgang mit dem Windows App SDK unterscheiden sich. WPF ist ein UI-Framework für mittelgroße bis große Geschäftsanwendungen mit auflösungsunabhängigem, vektorbasiertem Rendering, Data Binding, Styles/Templates und Commands, während WinUI als Teil des Windows App SDK ein modernes UI-Framework ist, das auf Fluent, hohem DPI und dem aktuellen Windows-Erlebnis aufbaut. Es als unkomplizierten Ersatz für WPF zu betrachten, ist riskant.

Welches sollte ich für eine Neuentwicklung wählen: WinForms, WPF oder WinUI?

Das hängt von der Art der Bildschirme und den Produktanforderungen ab. Wenn Sie ein kleines bis mittleres, auf Standardsteuerelementen und Eingabeformularen basierendes internes Tool schnell bauen wollen, ist WinForms immer noch ziemlich stark. Für eine mittelgroße bis große Geschäftsanwendung mit vielen Bildschirmen, bei der Sie Data Binding, Styles, Templates und MVVM richtig nutzen möchten, ist WPF meistens die sicherste Wahl. Bei einem neuen, ausschließlich für Windows bestimmten Produkt, dessen Produktwert unmittelbar von Fluent und einem modernen Windows-Erlebnis abhängt, ist WinUI eine starke Option. Ist der bestehende Altbestand groß, sollte man zunächst grundsätzlich prüfen, ob dessen Fortführung sinnvoll ist.

Sind WPF und WinForms inzwischen veraltet?

Man sollte sie nicht pauschal abschreiben. Sowohl WinForms als auch WPF verfügen auf dem aktuellen .NET über durchgängige Dokumentation und Migrationspfade und werden auch offiziell als aktive Windows-Desktop-UI-Frameworks behandelt. Gerade bei Geschäftsanwendungen wiegen Altbestand, Drittanbieter-Steuerelemente, Berichte und Druck, Gerätekopplung sowie Verteilungsverfahren normalerweise schwerer als die Aktualität des UI-Frameworks. Auch bei Neuentwicklungen ist es keine Seltenheit, dass WinForms oder WPF die reibungsärmste Wahl bleiben.

Muss ich zu WinUI wechseln, um die neuesten Windows-Funktionen zu nutzen?

Nein. Das Windows App SDK und WinUI sind nicht dasselbe - WinUI ist der UI-Framework-Teil des Windows App SDK. Das Windows App SDK selbst lässt sich auch bestehenden WPF-, WinForms- oder Win32-Anwendungen hinzufügen, und Funktionen wie App Lifecycle, Windowing oder Toast Notifications können sich in manchen Fällen einbinden lassen, ohne die aktuelle Oberfläche anzutasten. Es gibt also einen Weg, nur die benötigten Windows-Funktionen zu modernisieren, während WPF oder WinForms unverändert bleibt - eine vollständige UI-Migration ist nicht zwingend erforderlich.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.