Was 24 Jahre WinForms über Technologieentscheidungen für langlebige Software lehren

Vor einiger Zeit habe ich darüber geschrieben, warum ich C# WinForms noch lange nicht für tot halte.

Damals ging es vor allem um Pragmatismus: WinForms ist ausgereift, stabil, produktiv und für viele klassische Windows-Anwendungen immer noch erstaunlich gut geeignet.

2026 interessiert mich daran aber ein anderer Aspekt viel mehr.

Ich habe in meiner Laufbahn einige Technologien kommen und gehen sehen. Manche wurden als Zukunft präsentiert. Manche sollten bestehende Technologien ablösen. Manche waren technisch tatsächlich moderner.

Und trotzdem ist WinForms noch da.

Nicht irgendwie eingefroren in einer alten Version des .NET Frameworks, sondern als Bestandteil des aktuellen .NET. Microsoft liefert mit neuen .NET-Versionen weiterhin neue WinForms-Versionen aus. .NET 10 brachte unter anderem Dark Mode, vollständig integrierte asynchrone Formulare, Designer-Verbesserungen, Accessibility-Verbesserungen und neue APIs. Für .NET 11 befinden sich bereits weitere Änderungen in Entwicklung.

Das wirft für mich eine interessantere Frage auf:

Was passiert, wenn die Software, die wir heute entwickeln, länger lebt als die Technologie, auf der wir sie aufbauen?

Bei einer Website mag das ärgerlich sein.

Bei einem Automaten, einer Maschine, einem Kassensystem, einem Laborgerät oder einer industriellen Anlage kann es ein ernsthaftes wirtschaftliches Problem werden.

---

Eine Maschine denkt nicht in Releasezyklen

Softwareentwickler denken häufig in Jahren.

Industrie denkt teilweise in Jahrzehnten.

Eine Maschine, die heute für viel Geld installiert wird, kann 2040 noch irgendwo in einer Produktionshalle stehen. Ein Automat kann nach zehn Jahren noch vollkommen seinen Zweck erfüllen. Ein Messgerät wird nicht automatisch wertlos, nur weil sein Benutzerinterface nicht mehr dem aktuellen Fluent Design entspricht.

Das verändert die Architekturfrage fundamental.

Bei einem kurzlebigen Produkt kann ich relativ aggressiv auf neue Technologien setzen. Wenn ich ohnehin davon ausgehe, dass das System in fünf Jahren ersetzt oder grundlegend überarbeitet wird, ist das Risiko überschaubar.

Bei einem System mit 15 oder 20 Jahren erwarteter Lebensdauer sieht die Rechnung anders aus.

Dann muss ich nicht nur fragen:

Was kann diese Technologie heute?

Ich muss auch fragen:

Wie wahrscheinlich ist es, dass ich diese Technologie in zehn oder zwanzig Jahren noch vernünftig betreiben, bauen und warten kann?

Diese zweite Frage wird bei Architekturentscheidungen erstaunlich oft unterschätzt.

---

2002: WinForms

Windows Forms erschien mit dem ursprünglichen .NET Framework Anfang der 2000er-Jahre.

Aus heutiger Sicht ist das Framework alt.

Sehr alt.

Und trotzdem veröffentlicht Microsoft 2026 Dokumentation für WinForms auf .NET 11 Preview. Microsoft schreibt selbst, dass jede .NET-Version eine neue Version von Windows Forms mitbringt.

Mit .NET 10 kamen beispielsweise:

• asynchrone Forms und Dialoge,
• Dark Mode,
• Verbesserungen am Designer,
• neue Clipboard-APIs,
• Accessibility-Verbesserungen,
• ScreenCaptureMode,
• neue Analyzer,
• zahlreiche Bugfixes.

Für .NET 11 Preview dokumentiert Microsoft bereits weitere Arbeiten an Visual Styles, System Settings, Performance bei Bulk Operations, ToolStrip, Layout, Designer, PropertyGrid und Dark Mode.

Das ist ein bemerkenswerter Zustand.

Ein UI-Framework aus dem Jahr 2002 bekommt 2026 neue Funktionen.

---

Und was kam danach?

Genau hier wird die Geschichte interessant.

WinForms war keineswegs die letzte große UI-Technologie, die Microsoft vorgestellt hat.

Danach kamen zahlreiche neue Ansätze.

WPF

2006 erschien Windows Presentation Foundation.

WPF war gegenüber WinForms in vielen Bereichen ein erheblicher technologischer Schritt: XAML, Data Binding, Styles, Templates, Vektorgrafik, Animationen, eine wesentlich stärkere Trennung zwischen Darstellung und Logik und später die starke Verbreitung von MVVM.

Wenn man damals WPF gewählt hat, war das keineswegs eine schlechte Langzeitentscheidung.

Das muss man 2026 ausdrücklich festhalten.

WPF hat den Test der Zeit ebenfalls bestanden.

Microsoft entwickelt WPF weiterhin innerhalb von modernem .NET. .NET 10 brachte Performanceverbesserungen, Fluent-Style-Änderungen, neue APIs und weitere Verbesserungen. Auch .NET 11 Preview enthält bereits WPF-Änderungen.

WPF gehört deshalb nicht auf die Liste der gescheiterten WinForms-Nachfolger.

Es gehört zusammen mit WinForms auf die wesentlich interessantere Liste:

Windows-Desktoptechnologien, die tatsächlich langlebig geworden sind.

---

Silverlight

Dann kam Silverlight.

Silverlight war technisch interessant und zeitweise enorm präsent. Microsoft positionierte es für Rich Internet Applications und Anwendungen, die Teile der WPF-Welt in den Browser bringen sollten.

Wer damals auf die Technologie setzte, konnte dafür vollkommen nachvollziehbare Gründe haben.

Heute ist die Situation eindeutig.

Microsoft beendete den Support für Silverlight am 12. Oktober 2021.

Damit ist die Technologiegeschichte abgeschlossen.

Die Anwendungsgeschichte möglicherweise nicht.

Denn Software verschwindet nicht automatisch, wenn der Hersteller den Support beendet.

Irgendwo existiert möglicherweise weiterhin eine Fachanwendung, deren ursprüngliche Entwickler längst das Unternehmen verlassen haben und deren Geschäftslogik noch immer benötigt wird.

Das Problem wurde damit vom Hersteller zum Betreiber übertragen.

---

Windows 8, Metro und WinRT

Mit Windows 8 begann eine weitere große Neuausrichtung.

Microsoft wollte Windows auf PCs, Tablets und neue Geräteklassen ausrichten. Metro beziehungsweise die spätere Modern-UI-Welt unterschied sich fundamental vom klassischen Desktop.

WinRT, Windows Store Apps und die neuen App-Modelle sollten eine neue Generation von Windows-Anwendungen ermöglichen.

Technisch war vieles daran nachvollziehbar.

Strategisch war es trotzdem ein Risiko.

Denn auf diese Generation folgte bereits die nächste.

---

UWP: die Zukunft, die zur Wartungsplattform wurde

2015 kam die Universal Windows Platform.

Der Name transportierte bereits den Anspruch: eine gemeinsame Plattform für unterschiedliche Windows-Geräteklassen.

Desktop, Tablet, Xbox, HoloLens und andere Geräte sollten unter einem gemeinsamen Plattformmodell zusammengeführt werden.

Wenn jemand 2015 gesagt hätte:

„Für eine neue Windows-Anwendung nehme ich UWP. Das ist Microsofts Zukunft und WinForms ist Technologie von gestern.“

wäre das keine absurde Entscheidung gewesen.

Im Gegenteil.

Sie hätte damals ziemlich modern geklungen.

2026 beschreibt Microsoft UWP dagegen als maintenance mode und empfiehlt für aktuelle Entwicklung die Migration zum Windows App SDK.

Das bedeutet nicht, dass bestehende UWP-Anwendungen plötzlich nicht mehr funktionieren.

Das wäre eine zu vereinfachte Darstellung.

Es bedeutet aber etwas, das für langlebige Systeme mindestens genauso wichtig ist:

Die strategische Investition des Plattformherstellers hat sich verschoben.

Wer eine Anwendung über viele weitere Jahre entwickeln möchte, steht damit irgendwann vor einer Migrationsentscheidung.

Und Migration ist nicht kostenlos.

---

Xamarin.Forms

Auch Xamarin.Forms zeigt das Problem aus einer anderen Perspektive.

Cross-Platform-Entwicklung mit C# war attraktiv. Eine Codebasis für mehrere Plattformen versprach erhebliche Produktivitätsvorteile.

Später wurde .NET MAUI zum Nachfolger.

Microsoft beendete den Support für alle Xamarin-SDKs einschließlich Xamarin.Forms am 1. Mai 2024 und verweist für die Weiterentwicklung auf die Migration zu .NET beziehungsweise .NET MAUI.

Auch hier gilt:

Die ursprüngliche Technologieentscheidung muss deshalb nicht falsch gewesen sein.

Aber ihre Lebensdauer war begrenzt.

Für ein Produkt mit einem entsprechenden Modernisierungszyklus ist das akzeptabel.

Für ein System, das möglichst unverändert 20 Jahre betrieben werden soll, kann es problematisch sein.

---

Und WinForms?

Während all dieser Strategiewechsel passierte etwas fast Langweiliges.

WinForms blieb.

Nicht als aufregendste Technologie.

Nicht als modernste Technologie.

Nicht als Framework mit der elegantesten Rendering-Architektur.

Es blieb einfach verwendbar.

Und irgendwann wird genau diese Eigenschaft selbst interessant.

2002  WinForms
  │
  ├──── WPF ───────────────────────────────► aktiv
  │
  ├──── Silverlight ─────────► Supportende
  │
  ├──── Windows 8 / Metro
  │          │
  │          └──── WinRT / Store Apps
  │
  ├──── UWP ─────────────────► Maintenance
  │                              │
  │                              └──► Windows App SDK / WinUI 3
  │
  ├──── Xamarin.Forms ───────► Supportende
  │                              │
  │                              └──► .NET MAUI
  │
  └───────────────────────────────────────► WinForms 2026

Diese Darstellung soll nicht suggerieren, dass jede dieser Technologien als direkter WinForms-Nachfolger gedacht war.

Das wäre historisch falsch.

Sie zeigt etwas anderes:

Wie oft sich Microsofts Vorstellung moderner Anwendungsentwicklung verändert hat, während WinForms weiterhin verfügbar blieb.

---

Stellen wir uns jetzt einen Automaten vor

Nehmen wir keine gewöhnliche Office-Anwendung.

Nehmen wir einen Automaten.

Die konkrete Art spielt kaum eine Rolle:

• Ticketautomat,
• Verkaufsautomat,
• Check-in-Terminal,
• Zahlungsterminal,
• Produktionsautomat,
• Laborgerät,
• Messsystem,
• industrielle Bedienoberfläche.

Die Software könnte ungefähr so aufgebaut sein:

┌──────────────────────────────┐
│        Benutzeroberfläche    │
├──────────────────────────────┤
│       Application Logic      │
├──────────────────────────────┤
│          Domain Logic        │
├──────────────────────────────┤
│       Hardware Services      │
├──────────────────────────────┤
│ Serial / USB / CAN / TCP/IP  │
├──────────────────────────────┤
│ Treiber / Windows / Hardware │
└──────────────────────────────┘

Das System wird 2012 entwickelt.

Der Automat kostet vielleicht Zehntausende Franken.

Er funktioniert.

Der Kunde kauft 300 Stück.

Die Geräte werden verteilt.

Und dann beginnt der wirklich schwierige Teil der Softwareentwicklung:

Betrieb.

---

Der Code ist nicht mehr das eigentliche Problem

Nach zehn Jahren kennt kaum noch jemand das ursprüngliche Projekt vollständig.

Entwickler haben gewechselt.

Bibliotheken wurden aktualisiert.

Hardwarekomponenten wurden ersetzt.

Vielleicht gibt es einen neuen Drucker.

Einen anderen Scanner.

Ein neues Kartenlesegerät.

Ein neues Windows.

Neue Sicherheitsanforderungen.

Neue Zertifikate.

Neue Netzwerkregeln.

Trotzdem soll der Automat weiterhin dasselbe tun wie vorher.

Nun erreicht zusätzlich das UI-Framework das Ende seiner strategischen Lebensdauer.

Auf dem Papier klingt die Lösung einfach:

„Dann migrieren wir eben.“

Dieser Satz kann bei langlebiger Industriesoftware sehr teuer werden.

---

Eine UI-Migration ist selten nur eine UI-Migration

Man könnte zunächst denken:

Altes UI
   ↓
Neues UI

Fertig.

In der Realität sieht es eher so aus:

Neue UI-Technologie
       │
       ├── Navigation neu implementieren
       ├── Lifecycle verändert
       ├── Threading überprüfen
       ├── Binding überprüfen
       ├── Dialogverhalten überprüfen
       ├── Touch testen
       ├── Bildschirmtastatur testen
       ├── DPI / Skalierung testen
       ├── mehrere Displays testen
       ├── Drucker testen
       ├── Scanner testen
       ├── Kartenleser testen
       ├── Spezialhardware testen
       ├── Deployment anpassen
       ├── Logging überprüfen
       ├── Recovery-Verhalten testen
       └── vollständige Regression

Und das alles, obwohl der Benutzer möglicherweise keine einzige neue Funktion bekommt.

Das ist eine der unangenehmsten Arten technischer Schuld:

Kosten ohne unmittelbar sichtbaren Geschäftsnutzen.

---

Der Automat funktioniert doch

Das macht die Situation organisatorisch noch schwieriger.

Versuche einem Produktverantwortlichen zu erklären:

Wir müssen einen erheblichen Betrag investieren, damit die neue Version anschließend im Wesentlichen dasselbe macht wie die alte.

Die nachvollziehbare Antwort lautet:

Warum?

„Weil unser UI-Framework nicht mehr strategisch weiterentwickelt wird“ ist technisch eine legitime Begründung.

Betriebswirtschaftlich bleibt sie unangenehm.

Genau deshalb sollte die erwartete Lebensdauer einer Technologie bereits bei der ursprünglichen Architekturentscheidung berücksichtigt werden.

---

Technologie hat ebenfalls eine Halbwertszeit

Bei Architekturentscheidungen bewerten wir normalerweise Dinge wie:

• Performance,
• Entwicklungsproduktivität,
• Wartbarkeit,
• Skalierbarkeit,
• Testbarkeit,
• Sicherheit,
• Verfügbarkeit von Entwicklern,
• Lizenzkosten,
• Ökosystem,
• Tooling.

Ich würde bei langlebigen Systemen einen weiteren Punkt explizit hinzufügen:

Plattformrisiko

Darunter verstehe ich Fragen wie:

• Wie lange existiert die Technologie bereits?
• Wie groß ist die installierte Basis?
• Wie stark hängt sie von einem einzelnen Produktzyklus ab?
• Gibt es einen offenen Quellcode?
• Wie stark ist die Abwärtskompatibilität?
• Wie teuer wäre eine Migration?
• Gibt es einen realistischen Exit-Pfad?
• Wie oft hat der Hersteller seine Strategie in diesem Bereich bereits geändert?
• Ist die Technologie fundamental oder nur eine Abstraktionsschicht auf einer anderen Abstraktionsschicht?
• Kann ich die Anwendung notfalls jahrelang ohne neue Framework-Version betreiben?

Das sind Architekturfragen.

Keine nostalgischen Fragen.

---

Alter kann ein positives Signal sein

In der Softwareentwicklung behandeln wir Alter häufig automatisch als Nachteil.

Das ist zu einfach.

Eine 24 Jahre alte Technologie besitzt einen Nachteil:

Sie trägt historische Entscheidungen mit sich herum.

Aber sie besitzt gleichzeitig einen Vorteil, den eine zwei Jahre alte Technologie prinzipiell nicht besitzen kann:

einen 24-jährigen Track Record.

Bei WinForms wissen wir heute ziemlich viel.

Wir kennen seine Grenzen.

Wir kennen sein Threading-Modell.

Wir kennen seine Layout-Probleme.

Wir kennen DPI-Probleme.

Wir kennen seine Stärken.

Wir kennen seine Schwächen.

Wir wissen, wie man große Anwendungen damit strukturiert.

Wir wissen, wie man schlechte Anwendungen damit baut.

Wir wissen, wie man gute Anwendungen damit baut.

Und vor allem:

Wir wissen inzwischen, dass Microsoft eine enorme Menge an Kompatibilität erhalten hat.

Das ist empirische Information.

---

Das Lindy-Prinzip der Softwareentwicklung

Dahinter steckt eine interessante allgemeine Idee.

Vereinfacht besagt der sogenannte Lindy-Effekt bei nicht verderblichen Dingen:

Je länger etwas bereits existiert hat, desto plausibler wird eine weitere lange Existenz.

Das ist natürlich kein Naturgesetz für Software.

COBOL wird nicht automatisch unsterblich, nur weil es alt ist.

Und ein altes Framework kann morgen eingestellt werden.

Trotzdem enthält der Gedanke für Architekturentscheidungen etwas Wertvolles.

Vergleichen wir 2026 zwei Technologien:

Technologie A

• seit 24 Jahren produktiv eingesetzt,
• enorme installierte Basis,
• Open Source,
• Bestandteil von modernem .NET,
• bekommt weiterhin Updates.

Technologie B

• seit drei Jahren verfügbar,
• technisch moderner,
• kleinere installierte Basis,
• strategisch aktuell stark beworben.

Welche wird 2040 noch existieren?

Die ehrliche Antwort lautet:

Wir wissen es nicht.

Aber wir besitzen für Technologie A wesentlich mehr empirische Daten.

Das sollte in einer Risikoanalyse einen Wert haben.

---

Neu ist kein Synonym für langlebig

Das klingt banal.

In der Softwareentwicklung verhalten wir uns trotzdem regelmäßig anders.

Eine neue Technologie erscheint.

Sie löst reale Probleme.

Die Dokumentation sieht gut aus.

Der Hersteller investiert stark.

Konferenzen sprechen darüber.

Blogposts erklären die alte Technologie für tot.

Dann entsteht schnell folgende Gleichung:

neu = modern
modern = strategisch
strategisch = zukunftssicher

Der letzte Schritt ist falsch.

Modernität und Zukunftssicherheit sind zwei unterschiedliche Eigenschaften.

Eine Technologie kann technisch hervorragend und trotzdem nach acht Jahren strategisch abgelöst sein.

Eine andere kann technisch konservativ sein und 25 Jahre überleben.

---

Auch WinUI 3 muss diesen Test erst noch bestehen

Heute ist WinUI 3 Teil des Windows App SDK und Microsofts aktueller nativer UI-Stack für moderne Windows-Desktopanwendungen. Microsoft bezeichnet WinUI 3 entsprechend als natives UI-Framework für Windows-Desktop-Apps.

Das Windows App SDK wird aktiv entwickelt. Im August 2026 ist die 2.x-Linie aktuell; Microsoft dokumentiert Stable-, Preview- und Experimental-Kanäle sowie einen eigenen Release-Lifecycle.

Das ist alles positiv.

Es wäre deshalb falsch, WinUI 3 als schlechte Wahl darzustellen.

Aber für ein System mit einer erwarteten Lebensdauer bis 2045 gibt es eine Tatsache, die keine Architekturpräsentation beseitigen kann:

WinUI 3 hat noch keinen 20-jährigen Track Record.

WinForms hat ihn.

WPF inzwischen ebenfalls.

Das bedeutet nicht:

Nimm WinForms, weil WinUI 3 verschwinden wird.

Das wissen wir nicht.

Es bedeutet:

Berücksichtige, dass die langfristige Stabilität einer jungen Plattform zwangsläufig weniger empirisch belegt ist.

Das ist Risikomanagement.

---

Auch modernes .NET hat einen Lifecycle

Hier muss man allerdings fair bleiben.

WinForms auf modernem .NET bedeutet nicht, dass man 2026 eine Anwendung auf .NET 10 baut und diese Runtime anschließend bis 2045 offiziell unterstützt wird.

.NET selbst besitzt einen klar definierten Supportzyklus.

.NET 10 ist eine LTS-Version, veröffentlicht am 11. November 2025, und wird bis zum 14. November 2028 unterstützt. Microsoft veröffentlicht jährlich neue .NET-Hauptversionen.

Auch bei WinForms muss man deshalb Runtime-Upgrades einplanen.

Der entscheidende Unterschied ist:

Framework-Evolution ist etwas anderes als Framework-Ablösung.

Eine Anwendung von .NET 8 auf .NET 10 und später auf .NET 12 zu aktualisieren, ist konzeptionell etwas anderes, als die gesamte Presentation-Technologie von UWP auf WinUI 3 oder von Xamarin.Forms auf MAUI zu migrieren.

Beides kostet.

Aber die Risikoklassen sind unterschiedlich.

---

Die eigentliche Architekturmaßnahme ist Entkopplung

Aus all dem folgt allerdings nicht:

Baut alles mit WinForms.

Das wäre die falsche Schlussfolgerung.

Die bessere Schlussfolgerung lautet:

Baut langlebige Systeme so, dass der Tod einer UI-Technologie nicht den Tod des Systems bedeutet.

Bei einem industriellen System sollte die Architektur deshalb eher so aussehen:

┌──────────────────────────────────┐
│          Presentation            │
│ WinForms / WPF / WinUI / Web ... │
└────────────────┬─────────────────┘
                 │
                 ▼
┌──────────────────────────────────┐
│        Application Layer         │
│ Use Cases / Commands / Services  │
└────────────────┬─────────────────┘
                 │
                 ▼
┌──────────────────────────────────┐
│             Domain               │
│ Geschäfts- und Maschinenlogik    │
└────────────────┬─────────────────┘
                 │
                 ▼
┌──────────────────────────────────┐
│         Infrastructure           │
│ DB / Netzwerk / Geräte / I/O     │
└──────────────────────────────────┘

Dann ist WinForms nicht die Anwendung.

WinForms ist ein Adapter zur Anwendung.

Das ist ein fundamentaler Unterschied.

Wenn die Presentation-Schicht irgendwann ersetzt werden muss, bleibt die wertvolle Geschäfts- und Maschinenlogik erhalten.

---

Das gilt auch für WinForms selbst

Denn auch WinForms wird nicht ewig leben.

Zumindest sollte kein Architekt diese Annahme treffen.

Vielleicht existiert WinForms 2046 noch.

Vielleicht nicht.

Niemand weiß es.

Die Tatsache, dass WinForms bereits 24 Jahre überlebt hat, ist ein starkes Signal für Stabilität, aber keine Garantie für Unsterblichkeit.

Deshalb sollte auch eine neue WinForms-Anwendung nicht aus einer 30.000 Zeilen großen MainForm.cs bestehen.

Das Problem vieler alter WinForms-Systeme ist nicht WinForms.

Das Problem ist, dass UI, Geschäftslogik, Datenbankzugriff, Gerätekommunikation und Zustand miteinander verschmolzen wurden.

Dann wird aus einem Frameworkwechsel tatsächlich eine vollständige Neuentwicklung.

---

Boring Technology

In der Softwareentwicklung wird „boring“ häufig negativ verwendet.

Bei langlebigen Systemen kann boring hervorragend sein.

Boring bedeutet:

• bekannte Fehlerbilder,
• bekannte Einschränkungen,
• bekannte Deployment-Prozesse,
• verfügbare Entwickler,
• große Wissensbasis,
• wenig Überraschungen.

Ein Getränkeautomat muss technologisch nicht aufregend sein.

Er muss am Montagmorgen funktionieren.

Und am Dienstag.

Und nach einem Windows-Update.

Und nach dem Austausch des Druckers.

Und acht Jahre später, wenn niemand aus dem ursprünglichen Entwicklungsteam mehr dort arbeitet.

Das ist eine andere Definition von Qualität als die, die wir häufig bei neuen Frameworks verwenden.

---

Die wirtschaftliche Perspektive

Technologieentscheidungen werden häufig anhand der initialen Entwicklungskosten bewertet.

Für langlebige Software ist das unzureichend.

Die relevante Größe ist eher:

Total Cost of Ownership

= Entwicklung
+ Wartung
+ Updates
+ Betrieb
+ Schulung
+ Abhängigkeiten
+ Migrationen
+ Regressionstests
+ Plattformwechsel
+ Ausfallrisiko

Ein Framework, das die Entwicklung im ersten Jahr um 15 Prozent beschleunigt, aber nach acht Jahren eine große Migration erzwingt, kann über den gesamten Lebenszyklus teurer sein.

Umgekehrt kann eine konservative Technologie wirtschaftlich hervorragend sein, wenn sie 15 Jahre mit überschaubaren Updates weiterbetrieben werden kann.

Das lässt sich nicht allgemein für WinForms behaupten.

Aber es muss Bestandteil der Rechnung sein.

---

Die Maschine interessiert sich nicht für unseren Technologiegeschmack

Das ist vielleicht die wichtigste Erkenntnis.

Eine Maschine bewertet ihre Software nicht nach:

• GitHub-Stars,
• Hacker-News-Diskussionen,
• Konferenzvorträgen,
• Architekturtrends,
• Framework-Hype.

Sie stellt eine viel brutalere Frage:

Funktioniert das System zuverlässig?

Und der Betreiber stellt noch eine:

Was kostet es mich über seine gesamte Lebensdauer?

Aus dieser Perspektive sehen Technologieentscheidungen plötzlich anders aus.

---

Meine Bewertung 2026

Würde ich heute jede neue Windows-Anwendung mit WinForms bauen?

Nein.

Für ein modernes Consumer-Produkt mit aufwendiger UX würde ich andere Technologien evaluieren.

Für Cross-Platform ist WinForms offensichtlich ungeeignet.

Für hochgradig dynamische, responsive und stark animierte Benutzeroberflächen gibt es bessere Werkzeuge.

Aber würde ich WinForms 2026 für eine langlebige Windows-only Business-, Maschinen- oder Industriesoftware ernsthaft in Betracht ziehen?

Ja.

Nicht obwohl es alt ist.

Teilweise gerade deshalb.

Nicht weil WinForms technisch allen Alternativen überlegen wäre.

Das ist es nicht.

Sondern weil 24 Jahre Produktionsgeschichte selbst eine technische Eigenschaft darstellen.

---

WPF verdient dieselbe Anerkennung

Dasselbe gilt inzwischen in erheblichem Maße für WPF.

WPF ist jünger als WinForms, aber ebenfalls seit rund zwei Jahrzehnten produktiv im Einsatz und wird weiterhin mit modernem .NET weiterentwickelt. Microsoft dokumentiert sowohl Verbesserungen in .NET 10 als auch Arbeiten für .NET 11.

Für komplexere Windows-Oberflächen kann WPF deshalb eine sehr interessante Position einnehmen:

Es besitzt wesentlich modernere UI-Konzepte als WinForms und gleichzeitig einen inzwischen sehr langen Track Record.

Man sollte deshalb nicht die falsche Geschichte erzählen:

WinForms gut
WPF/UWP/alles danach schlecht

Die Realität ist interessanter:

WinForms ───────────────► überlebt

WPF ────────────────────► überlebt

Silverlight ────────────► beendet

UWP ────────────────────► Maintenance / Migration

Xamarin.Forms ──────────► Support beendet

WinUI 3 ────────────────► aktiv, Zukunft offen

.NET MAUI ──────────────► aktiv, Zukunft offen

Technologiegeschichte ist nicht linear.

---

Was ich daraus als Softwarearchitekt mitnehme

Ich habe Technologien kommen und gehen sehen.

Das hat meine Bewertung neuer Technologien verändert.

Ich frage heute weniger:

Ist das die modernste Lösung?

und häufiger:

Welche Art von Problem kaufe ich mir mit dieser Entscheidung für die nächsten 15 Jahre ein?

Neue Technologien können absolut die richtige Entscheidung sein.

Manchmal lösen sie Probleme, die mit älteren Technologien nur mit unverhältnismäßigem Aufwand lösbar wären.

Aber „neu“ ist kein Architekturargument.

„Microsoft empfiehlt es“ ist ebenfalls keine Garantie für eine Lebensdauer von zwanzig Jahren.

Und „alt“ ist nicht automatisch ein Gegenargument.

Bei langlebiger Software ist bewiesene Stabilität ein Wert.

---

Fazit

WinForms ist 2026 nicht deshalb interessant, weil es das modernste Windows-UI-Framework wäre.

Es ist interessant, weil es das offensichtlich nicht ist und trotzdem noch existiert.

Seit seiner Einführung hat die Windows-Entwicklung mehrere strategische Wellen erlebt.

Silverlight kam und ging.

Windows 8 brachte ein neues App-Modell.

UWP wurde als universelle Plattform aufgebaut und befindet sich heute im Wartungsmodus.

Xamarin.Forms wurde durch .NET MAUI abgelöst.

Windows App SDK und WinUI 3 sind heute die aktuelle strategische Richtung.

WPF und WinForms stehen immer noch.

Microsoft entwickelt beide weiterhin innerhalb von modernem .NET.

Das macht WinForms nicht automatisch zur richtigen Wahl.

Aber es widerlegt eine Denkweise, die in unserer Branche erstaunlich hartnäckig ist:

Dass die neueste Technologie automatisch die zukunftssicherste Technologie sei.

Für kurzlebige Software kann man dieses Risiko eingehen.

Bei einer Maschine, die zwanzig Jahre im Feld stehen soll, sollte man genauer rechnen.

Denn am Ende kann etwas passieren, das in keinem Architekturdiagramm besonders spektakulär aussieht:

Die Maschine lebt länger als ihr UI-Framework.

Und dann zeigt sich, ob die damalige Technologieentscheidung wirklich modern war – oder nur neu.

---

Quellen

Microsoft Learn – What’s new in Windows Forms
Dokumentation der WinForms-Entwicklung von .NET 5 bis .NET 11 Preview.
Microsoft: What’s new in Windows Forms

Microsoft Learn – What’s new in WinForms for .NET 10
Async Forms, Dark Mode, Designer-, Accessibility- und API-Verbesserungen.
Microsoft: WinForms in .NET 10

Microsoft Learn – What’s new in WPF
Aktuelle Entwicklung von WPF einschließlich .NET 10 und .NET 11 Preview.
Microsoft: What’s new in WPF

Microsoft Lifecycle – Silverlight
Microsoft beendete den Silverlight-Support am 12. Oktober 2021.
Microsoft: Silverlight End of Support

Microsoft Learn – Windows App Development
Microsoft beschreibt UWP als Maintenance-Plattform und Windows App SDK/WinUI 3 als aktuelle Richtung.
Microsoft: Windows App Development

Microsoft Learn – Windows App SDK Release Channels
Release- und Supportmodell des aktuellen Windows App SDK.
Microsoft: Windows App SDK Release Channels

Microsoft Learn – Xamarin to .NET migration
Microsoft-Support für Xamarin und Xamarin.Forms endete am 1. Mai 2024.
Microsoft: Upgrade Xamarin to .NET

Microsoft – .NET Support Policy
Aktuelle LTS-/STS-Lebenszyklen; .NET 10 LTS wird bis November 2028 unterstützt.
Microsoft: .NET Support Policy