GUI-Frameworks für .NET – Teil 1: Windows Forms
In .NET-Entwicklerkreisen gibt es seit Jahren hitzige Diskussionen über die Wahl des GUI-Frameworks. Diese Serie bietet eine Übersicht.
(Bild: erzeugt mit KI durch iX)
- Dr. Holger Schwichtenberg
Es existiert eine Vielfalt von GUI-Frameworks für .NET: Microsoft selbst bietet mehrere Alternativen und die Qual der Wahl ist inzwischen größer denn je, denn auch drei externe Anbieter mischen im Markt mit.
Die Tabelle in Abbildung 1 zeigt in den senkrechten Spalten die verfügbaren GUI-Frameworks, die Zeilen enthalten die wichtigsten Plattformen (Betriebssysteme und den Browser). Ein Eintrag in der Tabelle bedeutet jeweils, dass das betreffende GUI-Framework auf der Plattform läuft und mit welcher Art und Weise (Code, HTML/CSS, XAML oder andere XML-Sprache) sich die Oberfläche definieren lässt. Zusätzliche Symbole zeigen an, ob ein grafischer WYSIWYG-Designer vorhanden ist oder zumindest eine Vorschauansicht in der Entwicklungsumgebung existiert. Ebenfalls sind die kostenpflichtigen Lösungen markiert.
Manche Entwicklerinnen und Entwickler aus anderen Lagern lästern gerne über die Vielfalt der GUI-Frameworks, die Microsoft in den letzten Jahrzehnten hervorgebracht hat. An der Stelle sei daran erinnert, dass es der Java-Welt ähnlich erging und immer noch ergeht: Abstract Window Toolkit (AWT), Standard Widget Toolkit (SWT), Swing, JavaFX, Java Server Pages (JSP), Java Server Faces (JSF), Google Web Toolkit (GWT) usw.
(Bild: Holger Schwichtenberg)
Windows Forms
Windows Forms (oft abgekürzt mit WinForms) ist die älteste Desktop-Oberflächenbibliothek in .NET, die im klassischen .NET-Framework-Setup, aber auch in den modernen .NET-Versionen in der .NET Desktop Runtime (aktuelle Version: 9.0 vom 12. November 2024) noch enthalten ist und dort auch weiterhin verbessert wird. Die Klassen von Windows Forms befinden sich im Basisklassenbibliothek-Namensraum System.Windows.Forms.
Windows Forms basiert auf der klassischen Windows-Programmierschnittstelle (Win32 API). Man kann Windows Forms als eine Wrapper-Bibliothek für im Windows-Betriebssystem vorhandene Fenstertechniken und Steuerelemente verstehen.
Zusätzlich wird in Windows Forms die Windows-API GDI+ für die Grafikdarstellung verwendet (zum Beispiel Zeichnen von Formen, Rendern von Text und Bildern). Die Anpassung der Oberfläche und einzelner Steuerelemente an individuelle Wünsche ist aber oft sehr aufwendig und erfordert eine eigene Implementierung einer Ereignisbehandlung für das Paint()-Ereignis der Steuerelemente. Vermeintlich einfache Wünsche wie die Kreise mit den Prioritäten A, B und C und die Daten-Tooltips in einem DataGridView in Abbildung 2 erfordern schon einigen Programmcode. Transparenz ist für Windows Forms eine große Herausforderung.
(Bild: Holger Schwichtenberg)
Es gibt innerhalb der Entwicklungsumgebung Visual Studio einen mächtigen WYSIWYG-Designer für Windows-Forms-Oberflächen. Der Designer erzeugt aber nicht, wie heutzutage bei vielen GUI-Frameworks üblich, eine Markup-Sprache, sondern Programmcode in C# oder Visual Basic .NET. Entwicklerinnen und Entwickler, die die Oberfläche lieber durch Eintippen statt Klicken erstellen wollen, können den GUI-Programmcode selbst schreiben, was aber häufig aufwendig und fehleranfällig ist. Daher ist der Einsatz des Designers gebräuchlich, aber manchmal geht Copy & Paste im Editor doch schneller.
Videos by heise
Windows Forms wurde in .NET Framework 1.0 (erschienen am 13. Februar 2002) eingeführt und bekam in .NET Framework 2.0 einen großen Schub durch zahlreiche neue und verbesserte Steuerelemente. Windows Forms wurde im klassischen .NET Framework aber seitdem nicht mehr wesentlich weiterentwickelt, da Microsoft mit .NET Framework 3.0 die Windows Presentation Foundation (WPF) als Alternative eingeführt hat.
Am 23. September 2019 erschien Windows Forms dann aber im Rahmen von .NET Core 3.0 auch für das moderne .NET, läuft aber trotz der grundsätzlichen Plattformunabhängigkeit von .NET Core auch damit nur auf dem Windows-Betriebssystem (Windows 10 oder Windows Server 2012). In .NET Core 3.1 hat Microsoft einige ältere Windows-Forms-Steuerelemente ausgebaut, obwohl es diese in .NET Core 3.0 schon gab. Das war ein Verstoß gegen das Semantic Versioning, für den Microsoft sich aber entschuldigte.
Beweggrund für diese unerlaubten Breaking Changes war, dass Microsoft es sich bei der Portierung des Windows-Forms-Designers für Visual Studio einfacher machen wollte. Alle entfernten Steuerelemente wurden bereits in .NET Framework 1.0 eingeführt und es gab für sie ab .NET Framework 2.0 bessere Alternativen. Weitere ältere Steuerelemente sind in .NET 5.0 entfallen; dies stellte dann jedoch keinen Bruch gegen die Regeln des Semantic Versioning dar. Eine Migration einer Windows-Forms-Oberfläche vom klassischen .NET Framework zum modernen .NET ist mit geringem Aufwand möglich, sofern man nicht die älteren, entfallenen Steuerelemente verwendet.
Viele haben Windows Forms schon seit der Einführung von WPF totgesagt, doch tatsächlich erfährt es im modernen .NET eine Renaissance, denn in jeder der neueren .NET-Versionen gab es neue Features für Windows Forms. Hier nur einige Beispiele:
- .NET Core 3.0:
Application.SetHighDpiMode() - .NET 5.0: neues Steuerelement
TaskDialog - .NET 6.0: Windows Forms auf Windows ARM64,
Application.SetDefaultFont() - .NET 7.0: Model-View-ViewModel (MVVM) durch
ICommandfür Windows Forms im Stil der Windows Presentation Foundation (zunächst experimentell) - .NET 8.0: MVVM nun offiziell stabil (aber immer noch nicht so mächtig wie in WPF)
- .NET 9.0: Dark Mode und asynchrone Aufrufe von Fenstern
Zudem gab es zahlreiche Performanceverbesserungen für Windows Forms, siehe Abbildung 3, dort exemplarisch in .NET 6.0.
(Bild: Microsoft .NET Conf 2021)
Windows-Forms-Anwendungen mit reinen Bordmitteln wirken aus heutiger Sicht optisch altbacken. Die Anpassung des Designs der Steuerelemente ist grundsätzlich möglich, aber in der Implementierung oft sehr aufwendig. Es gibt aber einige kommerzielle Unternehmen, die zahlreiche Windows-Forms-Steuerelemente mit modernem Look & Feel sowie Anpassbarkeit durch Theming anbieten (siehe nachstehende Tabelle).
Microsoft liefert in Windows Forms einige Basissteuerelemente mit, aber höherwertige Steuerelemente wie Wizards, Ribbons, Karusselle, Docking Manager, Diagramme, Tabellenkalkulationen, Kalender, Berichte, PDF-Viewer und andere muss man kaufen: bei Komponentenanbietern wie DevExpress, Syncfusion, Telerik, Infragistics oder ComponentOne (siehe Tabelle). Microsoft sieht sich selbst als Anbieter der Basisinfrastruktur und hat keinerlei Bestrebungen, höherwertige Steuerelemente anzubieten. Das gilt nicht nur für Windows Forms, sondern für alle GUI-Frameworks von Microsoft.
| Hersteller | Produktname |
| DevExpress | WinForms Component Subscription |
| Telerik | UI for WinForms |
| Syncfusion | WinForms UI Controls Library |
| Mescius (vormals GrapeCity) | ComponentOne Studio for WinForms |
| Infragistics | Ultimate UI for Windows Forms |
| Text Control | TX Text Control .NET |
| Xceed | Grid, Chart, Editors, Input Validator, Docking Windows |
| Actipro | Windows Forms Controls |
Tabelle: Ausgewählte GUI-Komponentenanbieter für Windows Forms
Beim Verteilen von fertigen Anwendungen muss man zwischen klassischem .NET Framework und modernem .NET unterscheiden. Beim klassischen .NET Framework hat man immer ein sogenanntes Framework Dependent Deployment (FDD): Bevor man die Windows-Forms-Anwendung verteilen kann, muss das .NET Framework installiert werden. Das FDD gibt es auch noch im modernen .NET. Alternativ können Entwicklerinnen und Entwickler eine Self-contained App kompilieren, die alle benötigen Teile der Laufzeitumgebung und auch der Kernbibliothek mitbringt. Die Verbreitung von Windows-Forms-Anwendungen erfolgt über Installationsverfahren wie ClickOnce, MSI, MSIX, Microsoft Store, InstallShield, Inno Setup, Chocolatey, WinGet etc.
In Deutschland und weltweit arbeiten immer noch viele Entwicklerinnen und Entwickler an Windows-Forms-Anwendungen. Dies sind aber primär bestehende Anwendungen. Neuentwicklungen mit Windows Forms sind selten und finden hauptsächlich in Entwicklungsteams statt, die bisher schon mit Windows Forms arbeiten. Diese Zielgruppe will Microsoft mit den neuen Features in Windows Forms fördern.
(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.
