WPFDevelopers: a WPF control library that targets everything from .NET 4.0 to net10.0-windows

A control library for people still shipping WPF

WPFDevelopers is a C# library of WPF controls, published by the WPFDevelopers organisation and distributed on NuGet as WPFDevelopers. The project description says it covers the basic controls and a custom control library of screenshot controls, and the topic tags attached to the repository widen the scope to animation, map, markdown, themes and general user interface work in XAML. So the audience is specific: engineers who are shipping a Windows desktop application today and want a control set they did not write themselves. The project presents itself as a home for the basic controls plus custom ones, and the organisation maintains several mirrors of the work, on GitHub, on AtomGit and on Gitee, with a Chinese README available alongside the English one. That mirror set is a deliberate choice for a library whose user base includes developers in China, and it means a build server blocked from one host can still reach the source.

Eighteen target frameworks from net40 to net10.0-windows

The version matrix in the README is the most concrete fact about the library, and it is unusual to see a range this wide. The .NET Framework side is covered from net40 through net48 and net481, with net45, net451, net452, net46, net461, net462, net47, net471 and net472 all listed as supported. The modern side starts at netcoreapp3.0 and netcoreapp3.1 and continues through net5.0-windows, net6.0-windows, net7.0-windows, net8.0-windows, net9.0-windows and net10.0-windows. Every entry is marked as supported. Practically, that means one package can be referenced from a long lived .NET Framework application and from a current Windows targeted .NET application without maintaining a fork, which is the main reason a team would pick a shared control library over writing their own. The cost of that breadth is that the code has to stay within the oldest supported language surface, since net40 sits at the bottom of the range.

The preview package is where the new controls live

The README leads with a single instruction in large type: use the preview NuGet package for the latest. That is a meaningful choice for a library, because it separates the stable channel from the moving one and pushes adopters of new controls onto a channel that can change. The release history shows how young the package is. v0.1.0 was published on 2026-07-08, v0.2.0 on 2026-08-05 and v0.3.0 on 2026-10-07, with the last push on 2026-10-13. A version number below 1.0 is the convention for signalling that the public surface may still move, and here the project is explicit about it by pushing the newest work to the prerelease feed. For a team that pins versions, that means a decision to make on day one: take the stable channel and the controls that shipped with it, or take the preview and the newest ones. Nothing in the README promises a stability guarantee for the preview channel, and no support policy is stated.

A repository of samples, a reference project and documentation

The repository layout is simple enough to read in one screen. There is a src/ directory, a Reference/ directory, a docs/ directory and a Chinese README at the root next to the English one. The documentation centre points at a quick start in docs/en/getting-started.md, which is where a new user is expected to begin, and the README also links a short video on how to compile the project. The visual system is documented separately as a system design diagram, which is the kind of artefact that appears when a project wants adopters to extend it rather than merely consume it. A reference project alongside the source is a common pattern in control libraries, since it gives you a place to see controls hosted in a real application while you evaluate them. What is not in the repository is equally worth noting, because it shapes the evaluation: there is no separate changelog file and no public API documentation site named in the README, so the docs/ folder is the primary source of usage information.

What you actually get from a shared WPF control set

It helps to be clear about the category of thing this is. A WPF control library is a set of XAML ready controls, styles and resources that you reference from your application, usually with a namespace declaration in the app's XAML and a reference in the project file, after which the controls appear in the designer and in the toolbox. Beyond the basic controls, the parts that usually cost a team the most time are the ones this project advertises: screenshot controls, which capture a visual of a window or region, and markdown rendering, plus themed styling so an application does not have to invent its own visual language. The map and animation tags suggest further areas of coverage. The evaluation question is therefore not whether the library is good but whether the specific control you would otherwise spend a week on is in it, and because the newest controls sit in the preview package, the answer depends on which channel you install.

Where a shared control set is the wrong answer

There are honest reasons to skip a library like this. The first is version 0.x with the newest work in the preview feed, which is a poor fit for a product where an unexpected change in a control's API can break a release. The second is that WPF is Windows only, so none of this carries to a cross platform desktop or a web front end, and a team that has already committed to a different UI stack should not spend time on it. The third is the oldest target. Supporting net40 at the bottom of the range is what makes the package usable from legacy applications, but it also means the implementation lives inside the oldest supported API surface, and a team that wants modern language features inside its own controls may find that the library constrains them. Finally, the repository carries no stated support policy or roadmap beyond the release list, and the documentation is limited to what lives in docs/, so teams that need long term maintenance guarantees have to judge that themselves.

The alternative is WPF's own styling system, not another library

The realistic alternative to a third party control library is not a competing package but the platform itself. WPF already separates a control's behaviour from its appearance through styles, control templates and resource dictionaries, which means a team can restyle the built-in controls and get a consistent look without taking a dependency at all. The difference in approach is exactly that: a control library ships new behaviour, such as a screenshot control or a markdown view, and you accept its implementation and its version cadence, while the styling route ships only appearance and you keep full ownership of behaviour and of your own source. A hybrid is common in practice, taking the platform's own controls for the ordinary parts of a window and pulling a library in for the few controls that would be expensive to build, such as the screenshot control this project highlights. If the count of such controls in your application is zero, the styling route is the cheaper and more maintainable choice.

Editorial conclusion

Adopt WPFDevelopers when you are building a Windows desktop application on WPF and want a maintained set of controls rather than a hand rolled one, and when your target framework is already on the package's list. Do not adopt it expecting a 1.0 quality signal, since the project is still at v0.3.0 and tells you to install the preview package for the latest controls, and do not expect it to help a cross platform or web front end. Check first which NuGet channel you are pinning, stable or preview, then confirm the control you actually need is present in the version you install, and read the quick start in docs/en/getting-started.md. The last push was on 2026-10-13, the newest release is v0.3.0 from 2026-10-07, and the licence is MIT.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. WPFDevelopersOrg/WPFDevelopers on GitHub