dotnet/wpf: the Windows desktop UI framework, its source repo, and what it costs to adopt
WPF is a .NET Core UI framework for building Windows desktop applications.
At a glance
- What is it?
- WPF is the XAML-based UI framework for Windows desktop applications, and dotnet/wpf is the open source repository where it is developed for .NET. This is what the repository actually contains, how the README says to get started, and where the framework stops being the right answer.
- Who is it for?
- Adopt WPF if you are building a Windows-only desktop application and want XAML, data binding, and a vector renderer that scales on high DPI monitors, or if you maintain an existing WPF codebase and need it on modern .NET. Do not adopt it for cross-platform clients, for web or mobile delivery, or if your team cannot take a Windows-only build and test dependency.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What dotnet/wpf actually is, and who it is for
The repository is the source of Windows Presentation Foundation as it ships for .NET. The README describes WPF as a UI framework for building Windows desktop applications, covering an application model, resources, controls, graphics, layout, data binding and documents, with XAML as the declarative programming model. That list matters more than the label: WPF is not a control library you bolt onto a console app, it is an application model. It owns the message loop, the visual tree, dependency properties, routed events and the resource system.
The audience is narrow and specific. You are building a Windows desktop client, you want markup separated from code, and you are willing to accept a Windows-only runtime. The README states plainly that WPF and WinForms applications only run on Windows, and that both are part of the Microsoft.NET.Sdk.WindowsDesktop SDK. If any of those conditions is false, the rest of the framework's strengths do not compensate.
The code base is a fork of the WPF code in the .NET Framework. The README notes that .NET Core 3.0 shipped with a goal of parity with the .NET Framework version, and that over time the two implementations may diverge. That sentence is the honest summary of the project's relationship to its own history: this is not a rewrite, and it is not frozen either.
How the repository is laid out and how the framework renders
At the top level you find Microsoft.Dotnet.Wpf.sln, src/, packaging/, eng/, Documentation/ and the build entry points build.cmd, build.sh, Restore.cmd, start-vs.cmd and test.cmd. There is a global.json, which pins the SDK the build expects, and Directory.Build.props and Directory.Build.targets for shared MSBuild settings. The CI definitions are azure-pipelines.yml and azure-pipelines-pr.yml. That is a conventional .NET engineering layout, and it tells you the repo is set up to be built and packaged, not just read.
The rendering model is the part that shapes application code. The README says rendering is vector-based, which is why applications can scale on high DPI monitors. In practice this means your UI is a retained visual tree rather than a sequence of paint calls: you declare elements, the framework measures and arranges them, and it re-renders when properties change. Data binding connects that tree to your objects, so a property change on a view model updates the visual without you writing the update by hand. The README also points out the hosting model is flexible enough to host a video in a button, which is a compact way of saying WPF composes arbitrary content inside any element rather than restricting containers to a fixed set of children.
Two things about the layout are worth flagging. Tests live in a separate repository, dotnet/wpf-test, and the README states coverage there is limited at this time and will be added progressively. For anyone evaluating the project's quality signals, that is a real constraint on how much you can infer from the main repo alone. The second is that the repo carries a roadmap.md and the README's Status section says the team is currently developing WPF for .NET 10, with the roadmap holding the schedule for specific components.
Getting started: SDK downloads, daily builds, and the repository build
The README's Getting started section does not give an install command. It links to the .NET SDK download pages for 6.0, 7.0, 8.0 and 9.0, to a builds table for preview SDKs, and to Documentation/getting-started.md for instructions. So the first step is installing a .NET SDK from those links, not cloning this repository. Cloning dotnet/wpf is what you do to contribute to the framework, not to build an application with it. The README states that WPF and WinForms applications are part of the Microsoft.NET.Sdk.WindowsDesktop SDK, and that the most recent version of Visual Studio is recommended for developing them.
If you are working from the repository instead of an installed SDK, the README says Visual Studio 2022 Preview is required to build the WPF repo and contribute features and fixes for .NET 8.0. Documentation/getting-started.md covers installation for that path, and the README points to daily builds under that same document if you want to contribute and stay up to date with the team. The repository's own entry points for building are the scripts build.cmd, build.sh, Restore.cmd, start-vs.cmd and test.cmd, with global.json pinning the SDK the build expects.
Once a project exists, the XAML model is where the work happens. A window is declared in markup, and its code-behind is a partial class deriving from Window. That is the whole architecture in miniature: markup declares the visual tree, the partial class holds behaviour. For a first real use, set the window's DataContext to an object and bind a TextBlock's Text to one of its properties. When the property raises change notification, the text updates. If nothing appears, the usual cause is a missing DataContext or a binding path that does not match the property name; WPF does not throw on a failed binding by default, it renders nothing and reports the failure through the binding trace.
One more note from the README: the Visual Studio WPF designer has been available as part of Visual Studio 2019, and Blend supports drag-and-drop or direct XAML editing. The designer is a convenience, not a requirement, and the README does not claim it works identically for every project type.
Where WPF is the wrong tool
The README answers this more directly than most project pages. WPF and WinForms applications only run on Windows. There is no supported path in this material to running a WPF client on Linux or macOS, and the related search traffic asking about dotnet wpf linux has no corresponding answer in the repository. If your product needs one codebase for desktop and mobile, or a browser client, WPF is the wrong starting point and no amount of XAML familiarity changes that.
The second limitation is the .NET Framework boundary. The README states that issues with .NET Framework, including WPF, should be filed on the VS developer community or with Product Support, and should not be filed on this repository. Practically, that means a bug you hit in a .NET Framework 4.8 WPF application is not a dotnet/wpf issue and will not be fixed here, even though the code shares ancestry. Teams maintaining older applications need to know which side of that line they are on before opening anything.
The third is test coverage. The README is explicit that tests are published in a separate repository and have limited coverage at this time. That is a statement about the project's own verification posture, and it should temper any assumption that the main repository's green CI badge covers the behaviour your application depends on.
Finally, there is the migration cost. The README links a migration guide for moving .NET Framework WPF apps to .NET Core, which is an acknowledgement that the move is not automatic. The framework's surface is large, and the README's own framing, that the two implementations may diverge over time, means parity is a goal rather than a guarantee.
WPF against WinForms, and the parallel release lines
The README names WinForms as the other UI framework for Windows desktop applications supported on .NET, and notes both are part of the same Microsoft.NET.Sdk.WindowsDesktop SDK. The difference in approach is the programming model. WinForms gives you a designer-driven, control-and-event style API that maps closely to the underlying Windows controls; WPF gives you a declarative markup tree with data binding, styling, templating and vector rendering. If your UI is a form of labelled inputs and buttons, WinForms is less machinery. If you need restyling without recompiling layouts, or content composition that goes beyond what a control hierarchy expresses, WPF's model is the one that scales.
The release cadence is visible in the tags. Three releases are dated 2026-09-08: v9.0.20 for .NET 9.0.20, v8.0.31 for .NET 8.0.31, and v10.0.12 for .NET 10.0.12. Three parallel servicing lines means patches arrive on the older supported bands as well as the newest one, which matters if you are pinned to .NET 8 and cannot move.
Maintenance status is straightforward to state: the repository is not archived, and the last push was on 2026-09-21. The README's Status section says the team is currently developing WPF for .NET 10. That is the current state of the project as the repository records it.
Licence, contribution cost, and what an upgrade actually involves
The repository is MIT licensed, and the README states that .NET Core, including the WPF repo, is licensed under the MIT license, with the text in LICENSE.TXT. There is also a THIRD-PARTY-NOTICES.TXT at the top level, which is where bundled third-party terms live. MIT is permissive and imposes few obligations beyond preserving the notice, but I am not giving legal advice: if you redistribute binaries or embed the framework in a product with unusual distribution terms, have your own counsel read LICENSE.TXT and THIRD-PARTY-NOTICES.TXT rather than relying on the badge.
Upgrading an application is a framework-version decision, not a source decision. You consume WPF through the SDK, so moving from .NET 8 to .NET 9 or 10 means changing the target framework in your project file and rebuilding against the corresponding SDK from the README's download links. The three parallel release tags show that the older bands keep receiving patches, so staying on .NET 8 is a supported position rather than a forced march to the newest version.
Contributing to the framework itself is a different and much higher cost. The README directs contributors to Documentation/contributing.md and the general .NET Core contributing guide, and states that Visual Studio 2022 Preview is required to build the repo. There is a CODEOWNERS file and a .editorconfig, so style and review routing are enforced. The repository also carries a support statement for security reports: vulnerabilities go privately to the Microsoft Security Response Center at [email protected], with an expected response within 24 hours, not to the public issue tracker. If you plan to file bugs rather than patches, the README asks you to use the issue tracker for questions and bugs, and to keep .NET Framework problems on the VS developer community.
Editorial conclusion
Adopt WPF if you are building a Windows-only desktop application and want XAML, data binding, and a vector renderer that scales on high DPI monitors, or if you maintain an existing WPF codebase and need it on modern .NET. Do not adopt it for cross-platform clients, for web or mobile delivery, or if your team cannot take a Windows-only build and test dependency. Before committing, verify which SDK version your target framework requires, whether the Visual Studio designer works for your project type, and how the migration guide handles any .NET Framework APIs you depend on.
Frequently asked questions
What is WPF in dotnet?
WPF is Windows Presentation Foundation, a UI framework for building Windows desktop applications. The README describes it as supporting an application model, resources, controls, graphics, layout, data binding and documents, with XAML as a declarative programming model and vector-based rendering.
Is WPF obsolete?
The repository is not archived, its last push was on 2026-09-21, and the README's Status section says the team is currently developing WPF for .NET 10. Three release tags dated 2026-09-08 cover .NET 8, 9 and 10 servicing lines.
Does WPF still exist?
Yes. dotnet/wpf is the active repository for WPF on .NET, MIT licensed, with releases published in September 2026 and a roadmap.md describing project priorities and ship dates.
What is replacing WPF?
The README does not name a replacement. It states that WPF and WinForms applications only run on Windows and that both are part of the Microsoft.NET.Sdk.WindowsDesktop SDK, and it points to the WPF roadmap for component schedules rather than to a successor framework.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/dotnet-wpf)