microsoft/WPF-Samples: the official WPF sample set, retargeted to .NET 10

What WPF-Samples actually is, and who it is for

WPF-Samples is Microsoft's GitHub home for the Windows Presentation Foundation samples that originally lived on MSDN. The README describes it as a repository of samples that demonstrate API usage patterns and popular features for WPF in .NET for Desktop, and notes that the team is gradually moving interesting WPF samples over to GitHub.

The audience is narrow and specific: developers who already write C# and want to see a WPF feature working in a complete, buildable project rather than in a documentation snippet. The top-level directory listing reads like a table of contents for the framework itself. Data Binding, Animation, Threading, Drag and Drop, Element Tree, Globalization and Localization, Migration and Interoperability, PerMonitorDPI, Visual Layer, Speech and Media. If you need to know how a dispatcher behaves under load, or what the element tree looks like for a given control, there is a folder for that question.

It is not a library, not a template, and not a starter kit. Nothing in the repository is meant to be referenced from your own project. Each sample is a self-contained application you open, run, and read.

How the repository is laid out and what the two solution files mean

The root directory holds two solution files, WPFSamples.sln and WPFSamples.msbuild.sln, plus Directory.Build.props, global.json, NuGet.config and an azure-pipelines.yml. That structure is the first thing to understand, because the README draws a hard line between them: WPFSamples.msbuild.sln contains projects that can be built only with msbuild or Visual Studio, and will not compile with dotnet build. Those projects contain C++ code, for which dotnet build has no support.

Everything else is grouped by feature area in folders with spaces in their names, such as "Data Binding" and "Application Management", and by category for larger demos under Sample Applications and Getting Started. According to the README, most samples should work independently, which matters if you want to clone once and then open a single project rather than the whole solution.

The build configuration is centralized. Directory.Build.props at the root and global.json sit above the individual projects, and the README states that by default all the samples target .NET 10.0. The netframework branch holds an archive of samples targeting .NET 4.7.2, and the README also mentions release/x.x branches that require Visual Studio 2022 (v17.7) and the .NET 8 or .NET 9 SDK depending on the application.

Installing it and building a first sample

There is no installer and no package. The README gives two routes: clone with Git, or download the ZIP archive from the repository page. The ZIP route has one step people skip, and the README calls it out explicitly: before you unzip the archive, right-click it, select Properties, and then select Unblock.

Clone the repository first.

git clone https://github.com/microsoft/WPF-Samples

After cloning, the README says there will be two solution files in the root directory, WPF-Samples.sln and WPF-Samples.msbuild.sln. To build the samples, the README says to open one of the solution files in Visual Studio 2022 and build the solution. Note that the README uses the hyphenated file names in that sentence while the repository listing shows WPFSamples.sln and WPFSamples.msbuild.sln; trust the files that are actually in the directory.

The alternative the README gives is to navigate to the directory of a sample and build with dotnet build or msbuild, specifying the target project file.

dotnet build

Run that from inside a single sample directory. What you should see is a normal MSBuild restore and compile, followed by a build succeeded message. If the sample is one of the C++ projects, dotnet build will fail; that is the documented behaviour, not a broken checkout, and those projects belong to WPF-Samples.msbuild.sln instead.

The toolchain requirement is current and strict. The README states these samples require Visual Studio 2026 (v18.1) to build, test, and deploy, and also require the most recent .NET 10 SDK. If you are on Visual Studio 2022, the README points you at the release/x.x branches rather than main.

The accessibility warning is the most important line in the README

The README says the samples are generally about illustrating specific concepts and may go against accessibility best practices. That sentence is doing real work, and it is easy to skim past.

What it means in practice is that a sample can show you the shortest path to a feature while ignoring keyboard navigation, screen reader labelling, focus order or automation properties. If you copy a pattern out of a sample into a shipping application, you are copying a demonstration, not a reviewed implementation. The team acknowledges this directly and says it has spent time illustrating accessibility best practices in a subset of the samples, listing five: ExpenseItIntro, ExpenseItDemo, DataBindingDemo, CustomComboBox and EditingExaminerDemo. That subset is where you should look if accessibility is part of your requirement, and the rest of the repository should be treated as concept code.

There is a second limitation worth stating plainly. The repository has no versioned release stream in any meaningful sense. The most recent releases listed are from 2020-10-21 and cover Data Binding Demo and Editing Examiner Demo. The code on main has moved on to .NET 10 while the release tags describe a much older state. If you need a pinned, reproducible baseline, the release tags will not give you one.

Where WPF-Samples is the wrong tool

Reach for something else when you need a starting point for a real application. The samples are organized to isolate one concept at a time, which is the opposite of what an application skeleton needs. There is no cross-cutting architecture here to adopt, no dependency injection wiring, no navigation shell, no packaging or deployment story.

Reach for something else when your target is .NET Framework. The main branch targets .NET 10.0 by default. The README points to the netframework branch for the .NET 4.7.2 archive, so a .NET Framework 4.8 project will not find a matching sample on main.

Reach for something else when you are not on Windows. WPF is a Windows desktop framework, and nothing in this repository changes that. There is no cross-platform story to evaluate.

And reach for the actual WPF source when you need to know why something behaves the way it does. The README notes that WPF on .NET has been open-sourced and is now available at github.com/dotnet/wpf. Samples show usage; the framework repository shows implementation. Those are different questions.

Alternatives and how their approach differs

The most direct alternative is the WPF documentation on Microsoft Learn. Its unit is the prose page with short inline snippets, and it is organized around explaining a concept. WPF-Samples is organized around running one. A documentation snippet shows you three lines of XAML and tells you what they do; a sample gives you a project you can start, click through and modify. When a snippet is ambiguous, the sample resolves it, because you can watch the result.

The second alternative is the dotnet/wpf repository itself. That is the framework implementation, not usage examples. If you want to know which method a control calls internally, or whether a behaviour is a bug, that is where the answer lives. WPF-Samples will not tell you why; it will only show you what the public API does.

The third alternative is a general-purpose sample or template gallery for .NET desktop applications. Those tend to ship complete, opinionated application shells with navigation, theming and packaging already wired. WPF-Samples deliberately does not do that. It gives you breadth across framework features and almost no opinion about how an application should be assembled.

Maintenance, licence and what to check before depending on it

The repository is not archived, and the last push was on 2026-10-28, so it is current. That recency is consistent with the main branch having been retargeted to .NET 10 and requiring Visual Studio 2026 (v18.1). The cost of keeping up is therefore not zero: if you pin your learning material to this repository, your toolchain has to move with it. The README's own branch policy is the escape hatch, with release/x.x branches for Visual Studio 2022 and the .NET 8 or .NET 9 SDKs.

Licensing is straightforward on its face. The README states that unless otherwise mentioned, the samples are released under the MIT license, and the repository root carries a LICENSE file. MIT is permissive, so reusing a snippet in a commercial application is normally unproblematic. Two caveats are worth flagging without giving legal advice: the phrase unless otherwise mentioned means individual files or directories could carry different terms, and a sample is not a warranty of correctness, so the licence does not transfer any guarantee that the code is fit for production. Check the LICENSE file and any per-directory notices if you plan to redistribute.

Contributions go through pull requests or GitHub issues, per the README. There is no package to upgrade, so the upgrade cost is entirely about the .NET SDK and Visual Studio version you keep installed.

Editorial conclusion

Adopt WPF-Samples if you learn WPF by reading working code and want patterns for a specific feature area such as data binding, threading or drag and drop. Do not adopt it as an application skeleton or as a source of UI conventions, since the README says the samples generally illustrate concepts and may go against accessibility best practices. Before you build anything, confirm which solution file your target sample lives in: WPFSamples.msbuild.sln holds C++ projects that dotnet build cannot compile, so check that first.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/WPF-Samples on GitHub
4. README
5. Releases