# dotnet/winforms: What the .NET Wrapper Over User32 and GDI+ Actually Gives You > Windows Forms is a .NET UI framework for Windows desktop applications, distributed through the .NET SDK rather than a standalone installer. The repository holds only the .NET implementation, and its README sets an explicit bar for what new features it will accept. **dotnet/winforms** — Windows Forms is a .NET UI framework for building Windows desktop applications. - Repository: https://github.com/dotnet/winforms - Stars: 4,859 · Forks: 1,122 - Language: C# - License: MIT - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/dotnet-winforms ## What dotnet/winforms is, and the problem it solves Windows Forms is a .NET wrapper over Windows user interface libraries such as User32 and GDI+. That sentence from the README is the whole design in miniature: the framework does not draw its own widgets, it calls the Win32 controls that have shipped with Windows for decades and exposes them as .NET classes. The repository is a fork of the Windows Forms code from .NET Framework 4.8, migrated starting with .NET Core 3.0. The problem it solves is narrow and old. A team that needs a data-entry screen, a grid, a toolbar and a modal dialog on Windows can assemble that in the Visual Studio designer by dragging controls, and the result runs on the same native controls a Win32 developer would have used by hand. The README describes this as a Rapid Application Tool for Windows based Apps and says that principal sentiment has not changed. Who it is for, then, is the developer building a monolithic line-of-business application with complicated domain workflows, not someone building a media player, a mobile app or an IoT client. ## The bar for new features, and why the framework stays conservative Most UI frameworks publish a roadmap. This one publishes an exclusion list. The README states what would not make the bar for new functionality: features that modern desktop UIs like WPF or WinUI already have, functionality that would stretch a Windows desktop app into a mobile, multi-media or IoT app, and domain-specific custom controls already supplied by third-party vendors. That is an unusual thing to write down, and it is worth taking literally. If you are waiting for WinForms to grow a modern composition layer, the README is telling you it will not. What does make the bar is reactive: security changes where the Windows team moves an area out of process and WinForms apps take a performance hit under a new service pack, accessibility standards, HighDPI and per-monitor V2 scenarios, changed or extended Win32 control behaviour, and asynchronous call support so that backends can be modernized or migrated to the cloud. The framework follows Windows. It does not lead it. ## How the codebase is laid out and what the repository does not contain The repository is the implementation layer only, and the README is explicit about the two things missing from it. The .NET Framework variant of Windows Forms is not here; issues about it belong on the Developer Community or Product Support sites and should not be filed on this repository. The Windows Forms Designer implementations are not here either; designer issues go through the Visual Studio feedback tool or through the out-of-process designer issue template in this repo. The top-level layout matches that split. Source lives under src/, build and engineering infrastructure under eng/, and the build is driven by build.cmd on Windows and build.sh, with Restore.cmd for package restore. Winforms.sln is the solution file, WinForms.vsconfig lists the Visual Studio workloads a contributor needs, and start-vs.cmd and start-code.cmd launch the respective editors. Directory.Build.props, Directory.Build.targets and Directory.Packages.props centralize build and package settings. If you are evaluating the project as a dependency rather than contributing to it, none of this is your concern, but it explains why designer bugs and runtime bugs land in different places. ## Installing WinForms and building a first form There is no WinForms download in the sense of a separate installer. Windows Forms ships as part of the .NET SDK for Windows, so installing the SDK is installing the framework. The repository's own getting-started link points at the Microsoft documentation for building Windows Forms applications on .NET, and the README does not spell out the individual SDK commands itself. For contributors rather than application developers, the repository does document its own build entry points. Restore.cmd restores packages, and build.cmd and build.sh drive the build. ```bash Restore.cmd build.cmd ``` On a non-Windows machine the shell script is the equivalent entry point. ```bash ./build.sh ``` To open the solution in an editor, the repository provides start-vs.cmd for Visual Studio and start-code.cmd for VS Code, and WinForms.vsconfig lists the workloads a contributor needs installed. For application development, the README directs you to the Windows Forms .NET getting-started documentation instead of listing template commands, and it directs designer questions at the Windows Forms Designer documentation, which covers the differences between the .NET Framework designer and the .NET designer supporting .NET 6, 7, 8, 9 and later. That distinction matters: the .NET designer runs out of process, and the README treats it as a separate topic with its own documentation rather than something covered in the repository README. ## Where WinForms is the wrong tool The README answers this more directly than most project pages, because it names the categories it will not pursue. If your application needs the modern desktop UI capabilities that WPF or WinUI already provide, WinForms is the wrong choice and the maintainers have said so in the feature bar. If you need to run the same UI on Linux or macOS, the framework is a wrapper over Windows user interface libraries, so it cannot follow you off Windows. If you are targeting .NET Framework 4.8, this repository is not the place to file bugs, and the two runtimes have diverged through documented breaking changes since the fork. There is a further constraint that is easy to miss. The designer was built around 96 DPI, pixel-coordinated drag-and-drop design, and the README lists HighDPI and per-monitor V2 scenarios as ongoing modernization work rather than finished ground. Teams shipping to a mix of 4K and standard monitors should plan to verify layout behaviour themselves instead of assuming the designer produces it. Finally, the README notes that Visual Basic .NET developers are about 20 percent of WinForms developers and that, due to limited bandwidth, VB-specific changes that are only about correctness or code cleanliness cannot be prioritized. A VB team can use the framework, but should not expect the same responsiveness on language-specific fixes. ## WPF as the alternative, and the real difference The comparison people actually search for is WinForms against WPF, and the README gives a cleaner answer than a feature table would. WinForms is a wrapper over User32 and GDI+; each control is a handle to a native Windows control. WPF is not that. It renders its own visual tree and describes layout and appearance declaratively, which is why the README treats features that WPF already has as out of scope for WinForms rather than as gaps to close. That single architectural difference drives everything downstream. In WinForms you get native control behaviour for free, including whatever the Windows team changes in a service pack, and you inherit the pixel-coordinated design model that the README describes. In WPF you get a rendering stack the framework controls, and the styling and composition capabilities that come with it. For a data-entry application with a grid and a few dialogs, the WinForms path is shorter. For an application whose interface is the product, the README's own boundaries point you elsewhere. ## Maintenance, releases and the MIT licence The repository is not archived, and the last push was on 2026-09-22. Release streams are versioned per .NET line rather than as a single product: v9.0.16 and v8.0.27 were both published on 2026-05-12, and v11.0.0-preview.4 was published on the same day as a .NET 11 Preview 4 build. That structure is the upgrade cost in practice. WinForms moves with the .NET runtime, so picking up a WinForms fix generally means moving your target framework, which in turn means re-testing your third-party controls against a new TFM. The README addresses this directly for control vendors: at runtime, migrated control libraries are expected to work as before in the context of the new target framework, but design-time support may need migration work across a series of breaking-change areas. If your application depends on a vendor's designer integration, budget for that separately from the runtime upgrade. The licence is MIT, declared in LICENSE.TXT, with third-party notices in THIRD-PARTY-NOTICES.TXT. MIT is permissive and imposes no copyleft obligation on your application, but the third-party notices file exists because the repository includes components under other terms, so anyone redistributing a build should read it rather than assume a single licence covers everything. ## Conclusion Adopt dotnet/winforms if you are building a Windows-only line-of-business desktop application, you want the Visual Studio drag-and-drop designer, and your team is already on .NET. Do not adopt it if you need to run on Linux or macOS, if you need the modern desktop UI capabilities the README explicitly assigns to WPF and WinUI, or if you are targeting .NET Framework 4.8: that variant is not in this repository and its issues belong on the Developer Community site, not here. Before committing, verify two things. First, that your target framework maps to a supported release line, since the repository publishes separate release streams such as v9.0.16 and v8.0.27 alongside v11.0.0-preview.4. Second, that your third-party control vendor supports the .NET runtime, because the README warns that design-time support may need migration work even when runtime behaviour is unchanged. ## FAQ ### What is WinForms used for? It is used to build Windows desktop applications, particularly stable, monolithic line-of-business apps with complicated domain workflows and rich user interfaces. The README describes it as a Rapid Application Tool for Windows based Apps, built on a visual what-you-see-is-what-you-get designer. ### Is WinForms still used today? The repository is not archived and the last push was on 2026-09-22, with release streams such as v9.0.16, v8.0.27 and v11.0.0-preview.4 published in 2026. The README also notes that Visual Basic .NET developers make up about 20 percent of WinForms developers. ### What are the limitations of WinForms? It is a wrapper over Windows user interface libraries, so it does not run off Windows, and the README excludes features that WPF or WinUI already have, functionality that would stretch a desktop app into mobile, multi-media or IoT, and custom controls already supplied by third-party vendors. It also notes that the designer was built around 96 DPI, pixel-coordinated drag-and-drop design, with HighDPI and per-monitor V2 listed as ongoing modernization areas. ### How do I install WinForms in Visual Studio? There is no separate WinForms installer; it ships with the .NET SDK for Windows, so you install the SDK and then use the Windows Forms .NET getting-started documentation the README links to. To use the visual designer, open the project in Visual Studio; the README points designer questions at the Windows Forms Designer documentation covering the .NET out-of-process designer. ### Which is better in 2026, WPF or WinForms? The README does not rank them, but it does draw a boundary: features that modern desktop UIs like WPF or WinUI clearly already have are listed as things that would not make the bar for new WinForms functionality. WinForms remains a wrapper over User32 and GDI+ for line-of-business Windows apps, while WPF is treated as the place where modern desktop UI capabilities live. ## Sources - [dotnet/winforms on GitHub](https://github.com/dotnet/winforms) - [Issues](https://github.com/dotnet/winforms/issues) - [License: MIT](https://github.com/dotnet/winforms/blob/main/LICENSE) - [README](https://github.com/dotnet/winforms/blob/main/README.md) - [Releases](https://github.com/dotnet/winforms/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dotnet-winforms