Modern.Forms: a cross-platform Winforms style toolkit for .NET

A Winforms shaped API where the layout lives in C#

Modern.Forms positions itself as an open source cross platform spiritual successor to Winforms. The design goal is stated as a list: cross platform across Windows, Mac and Linux, familiar for Winforms developers, suitable for line of business applications and quick apps, and updated with modern controls and modern aesthetics.

The part that most affects how you write code is the second bullet, which says the API should be familiar for Winforms developers and, in parentheses, not XAML. So the interface is built in code rather than in a markup language. The repository layout shows how that plays out in practice. Under `samples/Explorer/` there is a `MainForm.cs` alongside a `MainForm.Designer.cs`, a split that anyone who has opened a Winforms project will recognise, since the designer file is where the generated control tree normally lives.

That split is also the interesting part for anyone evaluating the project. A code first toolkit in a Winforms shape means the designer story is not the same as in Winforms, and the readme does not describe how far the visual designer support goes. The library itself lives under `src/`, with `tests/` and `samples/` at the top level, alongside `Modern.Forms.sln` and two central build files, `Directory.Build.props` and `Directory.Packages.props`.

The showcase is an application that decompiles .NET assemblies

The readme points at a standalone sample, `ModernDecompile`, as the quickest way to see the toolkit in action. Its source lives in a separate repository, and it is published as a .NET global tool, so the whole demonstration is two commands.

dotnet tool install --global ModernDecompile
decompile

The instructions say to run this from a Windows, Mac or Linux command line with .NET 6 installed. The second command launches the sample application, which is built with `Modern.Forms` and lets you decompile .NET assemblies.

That is a smart choice of showcase. A decompiler is a dense, stateful desktop application with a tree view, a text output pane, menus and a toolbar, which exercises far more of a widget toolkit than a Hello World window would. It also happens to be a program most developers already have a reason to run.

Inside the `Modern.Forms` repository itself there are three smaller samples. `ControlGallery` is a gallery of the controls the toolkit includes, `Explore` is described as a Windows Explorer clone and `Outlaw` as a Microsoft Outlook clone. The readme refers to `docs/samples.md` for how to build and run them, so the samples are meant to be compiled rather than downloaded.

Starting a new project means reading docs/getting-started.md

For creating your own application, the readme does not give inline instructions. It links to `docs/getting-started.md`, and the `docs/` directory sits at the top level of the repository next to `samples/` and `src/`.

The one command sequence the readme gives you directly is the global tool install shown earlier, which covers running the decompiler sample. Everything else, from creating a project file to referencing the packages to launching a window, is delegated to the documentation.

Two build details are visible in the repository layout rather than the readme. `Directory.Build.props` and `Directory.Packages.props` are present at the top level alongside `Modern.Forms.sln`. Central package management through a `Directory.Packages.props` file is how a multi project solution keeps one version per dependency across the whole tree, which matters when you are building the library, its tests and three samples that all have to agree on the same package versions.

There is also a `tests/` directory at the top level, and a `.github/` directory with a workflow whose badge is labelled.NET Build, so the project runs its own build in CI. The readme carries that build badge as a status indicator.

Early stage warning, and two different .NET versions in play

The readme opens with a warning that is worth taking literally: the framework is currently in its early stages and you should use it at your own risk. That is the project's own assessment of itself, not an outside opinion, and it should shape your evaluation.

There is a version inconsistency worth flagging as well. The repository description calls Modern.Forms a cross-platform spiritual successor to Winforms for.NET 8+, while the readme body says it is for.NET 6, and the command line instructions for the sample say to have.NET 6 installed. So the documented target has moved at some point without the readme catching up, and you should check `docs/getting-started.md` for the target framework the current `src/` projects actually build against.

The release history reinforces the early stage reading. The listed releases are v0.1, an initial release dated 2020-03-18, v0.2 dated 2020-05-13 and v0.3 dated 2022-09-21. Nothing has been published as a release in the years since, while the last push to the default branch was on 2026-04-08. There is no packaged distribution on a regular cadence, which for a UI toolkit means the version you consume is a git reference rather than a stable, versioned package.

The licence is MIT, with the text in `license.md` at the repository root, and there is a separate `third-party-licenses.md` recording the licences of bundled dependencies, which is the file to read if you intend to ship a binary that includes them.

When Modern.Forms is the wrong choice

The clearest case against it is the one the readme itself points at. If what you want is an open source cross platform successor to WPF, the readme says to look at Avalonia instead. The two projects answer different questions. WPF is an XAML, markup first framework, and Avalonia follows that shape. Modern.Forms deliberately goes the other way, keeping the Winforms code first idiom, so a team with WPF habits and a team with Winforms habits end up choosing differently.

The second case is any application where the control surface has to be guaranteed. A toolkit that describes itself as early stage and whose newest release is v0.3 from 2022-09-21 can be perfectly adequate for an internal tool written by the same people who maintain it. It is a poor foundation for a product where a missing control or a changed property means a release slip, because the guarantee is not there. The `ControlGallery` sample exists precisely to let you inventory what exists, which is also a signal that the set is not yet comprehensive.

The third case is a team that wants a visual designer. The readme stresses familiarity with Winforms, and the Explorer sample keeps a `MainForm.Designer.cs`, but the documentation available in the repository does not describe designer tooling, theming or accessibility support, so anyone whose workflow depends on a designer is evaluating against an unknown.

How a code first toolkit differs from a markup first one

The trade between Modern.Forms and a markup driven toolkit is not really about features. It is about where the interface description lives and who is allowed to edit it.

In a code first toolkit, the visual tree is C# objects with properties. You construct them, set properties, add them to a parent, and layout is code. The advantages are that the full language applies, so conditional layout and data binding logic sit in ordinary C# rather than in a restricted expression language, and that there is no separate compilation step or designer process to keep in sync. The costs are that a designer cannot safely edit the form, that diffs of a form are diffs of code, and that anything visual is only as good as the code that produces it.

In a markup first toolkit the designer can open a XAML file and drag controls, and non programmers can adjust layout. The cost is the opposite: a restricted expression language, a build step for the markup, and a separate designer process.

Modern.Forms is betting on the first model for a specific audience. The readme names line of business applications and quick apps as the intended use, and the Explorer and Outlook clone samples are exactly the kind of dense internal tool that a code first approach suits. If your team is shipping a consumer facing desktop product with a design team attached, that bet is the wrong one to inherit.

Editorial conclusion

Modern.Forms suits a .NET team that wants a Winforms style, code first desktop UI and is prepared to work on an early stage framework, and it is the wrong choice for anything needing a stable control set or a maintained release cadence. Before adopting it, check the Getting Started guide in docs/getting-started.md against the .NET version your application targets, because the readme says .NET 6 while the repository description says .NET 8+, and run the `ControlGallery` sample to see which controls actually exist, since the newest published release is v0.3 from 2022-09-21.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. modern-forms/Modern.Forms on GitHub
4. README
5. Releases