GUI frameworks for .NET – Part 1: Windows Forms

In .NET developer circles, there have been heated discussions about the choice of GUI framework for years. This series provides an overview.

listen Print view
Lead story .NET

(Image: erzeugt mit KI durch iX)

10 min. read
By
  • Dr. Holger Schwichtenberg
Contents

There is a variety of GUI frameworks for .NET: Microsoft itself offers several alternatives and the agony of choice is now greater than ever, as three external providers are also involved in the market.

The table in Figure 1 shows the available GUI frameworks in the vertical columns, the rows contain the most important platforms (operating systems and the browser). An entry in the table means that the GUI framework in question runs on the platform and the way in which the interface can be defined (code, HTML/CSS, XAML or other XML language). Additional symbols indicate whether a graphical WYSIWYG designer is available or at least a preview view exists in the development environment. The paid solutions are also marked.

Some developers from other camps like to complain about the variety of GUI frameworks that Microsoft has produced in recent decades. At this point, it is worth remembering that the Java world has experienced and continues to experience a similar situation: Abstract Window Toolkit (AWT), Standard Widget Toolkit (SWT), Swing, JavaFX, Java Server Pages (JSP), Java Server Faces (JSF), Google Web Toolkit (GWT), etc.

GUI frameworks and platforms in .NET 9.0 (Fig. 1)

(Image: Holger Schwichtenberg)

Windows Forms (often abbreviated to WinForms) is the oldest desktop interface library in .NET, which is still included in the classic .NET framework setup, but also in the modern .NET versions in the .NET Desktop Runtime (current version: 9.0 from November 12, 2024) and is still being improved there. The classes of Windows Forms are located in the base class library namespace System.Windows.Forms.

Windows Forms is based on the classic Windows programming interface (Win32 API). Windows Forms can be considered a wrapper library for window techniques and control elements available in the Windows operating system.

In addition, Windows Forms uses the Windows API GDI+ for graphics display (e.g., drawing shapes, rendering text and images). However, adapting the interface and individual controls to individual requirements is often very complex and requires a separate implementation of event handling for the Paint() event of the controls. Supposedly simple requests such as the circles with the priorities A, B and C and the data tooltips in a DataGridView in Figure 2 already require some program code. Transparency is a major challenge for Windows Forms.

In this simple Windows Forms application, a few tricks were already necessary to display the circles with priorities A, B and C as well as data-based tooltips in the DataGridView (Fig. 2).

(Image: Holger Schwichtenberg)

There is a powerful WYSIWYG designer for Windows Forms interfaces within the Visual Studio development environment. However, the designer does not generate a markup language, as is common today with many GUI frameworks, but program code in C# or Visual Basic .NET. Developers who prefer to create the interface by typing instead of clicking can write the GUI program code themselves, but this is often time-consuming and error-prone. Therefore, the use of the Designer is common, but sometimes copy & paste in the editor is faster.

Videos by heise

Windows Forms was introduced in .NET Framework 1.0 (released on February 13, 2002) and got a big boost in .NET Framework 2.0 with numerous new and improved controls. However, Windows Forms has not been significantly further developed in the classic .NET Framework since then, as Microsoft introduced the Windows Presentation Foundation (WPF) as an alternative with .NET Framework 3.0.

On September 23, 2019, however, Windows Forms was also released for modern .NET as part of .NET Core 3.0, but despite the fundamental platform independence of .NET Core, it only runs on the Windows operating system (Windows 10 or Windows Server 2012). In .NET Core 3.1, Microsoft has removed some older Windows Forms controls, although these already existed in .NET Core 3.0. This was a violation of semantic versioning, for which Microsoft apologized.

The reason for these unauthorized breaking changes was that Microsoft wanted to make things easier for itself when porting the Windows Forms Designer to Visual Studio. All removed controls were already introduced in .NET Framework 1.0 and there were better alternatives for them from .NET Framework 2.0 onwards. Other older controls were removed in .NET 5.0; however, this did not constitute a breach of the semantic versioning rules. Migrating a Windows Forms interface from the classic .NET Framework to modern .NET is possible with little effort, as long as you do not use the older, dropped controls.

Many have been calling Windows Forms dead since the introduction of WPF, but it is actually experiencing a renaissance in modern .NET, as there have been new features for Windows Forms in each of the newer .NET versions. Here are just a few examples:

  • .NET Core 3.0: Application.SetHighDpiMode()
  • .NET 5.0: new control element TaskDialog
  • .NET 6.0: Windows Forms on Windows ARM64, Application.SetDefaultFont()
  • .NET 7.0: Model-View-ViewModel (MVVM) through ICommand for Windows Forms in the style of the Windows Presentation Foundation (initially experimental)
  • .NET 8.0: MVVM now officially stable (but still not as powerful as in WPF)
  • .NET 9.0: Dark mode and asynchronous window calls

There were also numerous performance improvements for Windows Forms, see Figure 3, there as an example in .NET 6.0.

Performance improvements for Windows Forms in .NET 6.0 (Fig. 3)

(Image: Microsoft .NET Conf 2021)

From today's perspective, Windows Forms applications with pure on-board tools look outdated. Customizing the design of the control elements is possible in principle, but is often very complex to implement. However, there are some commercial companies that offer numerous Windows Forms controls with a modern look & feel and customizability through theming (see table below).

Microsoft provides some basic controls in Windows Forms, but higher-level controls such as wizards, ribbons, carousels, docking managers, charts, spreadsheets, calendars, reports, PDF viewers and others must be purchased from component providers such as DevExpress, Syncfusion, Telerik, Infragistics or ComponentOne (see table). Microsoft sees itself as a provider of the basic infrastructure and has no intention of offering higher-quality control elements. This applies not only to Windows Forms, but to all Microsoft GUI frameworks.

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

Table: Selected GUI component providers for Windows Forms

When distributing finished applications, a distinction must be made between the classic .NET Framework and modern .NET. With the classic .NET Framework, there is always a so-called Framework Dependent Deployment (FDD): The .NET Framework must be installed before the WPF application can be distributed. The FDD is also still available in modern .NET. Alternatively, developers can compile a self-contained app that includes all the required parts of the runtime environment and the core library. Windows Forms applications are distributed via installation methods such as ClickOnce, MSI, MSIX, Microsoft Store, InstallShield, Inno Setup, Chocolatey, WinGet etc.

In Germany and around the world, many developers are still working on Windows Forms applications. However, these are primarily existing applications. New developments with Windows Forms are rare and mainly take place in development teams that already work with Windows Forms. Microsoft wants to support this target group with the new features in Windows Forms.

Heise conference: betterCode() .NET 10.0 on November 18th
Online conference betterCode() 10.0 on November 18, 2025

(Image: coffeemill/123rf.com)

The next LTS release is coming: At the online conference betterCode() .NET 10.0 on November 18, 2025 – hosted by iX and dpunkt.verlag in cooperation with IT-visions.de –, the author of this article, Dr. Holger Schwichtenberg, and other experts will present the most important new features. These include the updates in the .NET 10.0 SDK as well as 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 and the integration of artificial intelligence in .NET applications.

The program has not yet been published – until then, discounted blind-bird tickets are already available in the online store. Last year's program can be viewed in the archive.

Don't miss any news – follow us on Facebook, LinkedIn or Mastodon.

This article was originally published in German. It was translated with technical assistance and editorially reviewed before publication.