WPF-Samples: Microsoft's official map of a desktop framework

MSDN's samples, migrated and retargeted

The repository's stated purpose is to demonstrate API usage patterns and popular features of the Windows Presentation Foundation in .NET for Desktop, and its history is written into its own README: these samples were initially hosted on MSDN, and the interesting ones are being gradually moved to GitHub. The migration has a modernization edge, all samples have been retargeted to .NET 10.0, while a netframework branch keeps an archive of the samples as they targeted .NET Framework 4.7.2, so both the current framework and its classic predecessor remain readable in one place. The context completes with a pointer to dotnet/wpf, where WPF itself was open-sourced, making this samples repo the companion to a framework whose source you can also read. Everything is MIT licensed unless a sample says otherwise, and contributions arrive through pull requests and issues.

Twenty-six directories that mirror the framework

The repository's root is a taxonomy, and reading it is the fastest way to learn what WPF contains: Accessibility, Animation, Application Management, Clipboard, Compatibility, Data Binding, Documents, Drag and Drop, Element Tree, Elements, Events, Getting Started, Globalization and Localization, Graphics, Input and Commands, Migration and Interoperability, PerMonitorDPI, Resources, Sample Applications, Speech and Media, Styles and Templates, Threading, Visual Layer and Windows, plus Tools and Properties directories. Each is a shelf of focused projects demonstrating that subsystem, and the names double as a syllabus, a newcomer can walk the list and discover subsystems they did not know existed, PerMonitorDPI being the classic surprise. The Sample Applications directory holds the larger composites, complete enough to read as small programs rather than fragments, and Getting Started contains the walkthrough that anchors the whole learning path.

Two solution files and the C++ exception

After cloning, the root contains two solution files, WPF-Samples.sln and WPF-Samples.msbuild.sln, and the difference between them is documented precisely. The ordinary solution opens in Visual Studio and builds the managed samples. The msbuild solution contains projects that can only be built with msbuild or Visual Studio and will not compile with dotnet build, because they contain C++ code, for which dotnet build has no support. That split is a small piece of .NET archaeology made practical: most samples build with the modern, cross-platform toolchain, and the ones that interop with native code stay on the Windows-native one. Per-sample building is also supported, navigating to a sample's directory and running dotnet build or msbuild against its project file, which is the workflow of choice when you only care about one subsystem. Keeping the two solutions separate rather than flagging projects inside one is the quiet courtesy, since a solution that half-fails under a given toolchain teaches developers to distrust all of them.

Visual Studio 2026 for main, 2022 for the older branches

The tooling requirements are versioned per branch with unusual clarity. The main branch, targeting .NET 10, requires Visual Studio 2026 version 18.1 and the most recent .NET 10 SDK to build, test and deploy, with the free Community edition linked directly. The release branches for older .NET versions require Visual Studio 2022 version 17.7, with the appropriate SDK per application, and the README links the .NET 9 and .NET 8 downloads alongside. Repository infrastructure supports the split: a Directory.Build.props carries shared build settings, global.json pins the SDK, and eng plus azure-pipelines.yml drive CI. For teams maintaining applications across framework generations, the branch structure means the same sample can be consulted at the version matching production, which matters for a framework whose API surface has shifted in twenty years of evolution.

An accessibility caveat, stated up front

The README contains a disclaimer few sample collections would write: the samples are generally about illustrating specific concepts and may go against accessibility best practices, because code trimmed to demonstrate one mechanism omits the scaffolding real applications need. Rather than leaving it there, the team identifies the subset where accessibility best practices are deliberately illustrated, ExpenseItIntro, ExpenseItDemo, DataBindingDemo, CustomComboBox and EditingExaminerDemo, alongside a whole Accessibility directory of samples on the topic itself. This two-tier honesty serves two audiences correctly, the developer copying a mechanism gets a warning not to copy the whole posture, and the developer shipping to users gets named examples worth imitating. It also acknowledges that sample code teaches more than its subject, which is exactly why the caveat matters.

Getting started runs through ExpenseIt

The learning path begins in the Getting Started directory with the walkthrough for a first WPF application, built in C#, which constructs the ExpenseIt introduction application step by step, and continues into Sample Applications with the more complete ExpenseItDemo. Following the same application from walkthrough to demo is a deliberate shape, the reader builds the small thing once with guidance, then reads the larger thing that adds the practices the walkthrough could not carry. DataBindingDemo, CustomComboBox and EditingExaminerDemo extend the same tier, complete applications each centered on a subsystem the framework is known for, data binding being the mechanism WPF organized itself around and editing commands being the one newcomers most often underestimate. The demo release tags in the repository's history, with names like Data Binding Demo and Editing Examiner Demo, record which of these were considered milestones during the migration.

Clone, or download, unblock and build

Two acquisition paths are documented. With Git:

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

Without Git, the ZIP of the current version downloads from the repository, and the README's notes for that path carry genuinely hard-won advice: before unzipping, right-click the archive, open Properties and select Unblock, because Windows marks downloaded files and the zone marker propagates into the extracted sources, breaking builds in ways that look like toolchain bugs. The remaining notes state the operating model, most samples work independently, so partial extraction is viable, and all samples target .NET 10.0 by default on the main branch. The repository carries a SECURITY.md and CODEOWNERS, was last pushed on 2026-09-22, and its release list preserves the 2020-era numeric tags from the MSDN migration as fossils of the move.

Editorial conclusion

Use WPF-Samples when learning or teaching Windows Presentation Foundation on modern .NET, or when checking how a specific subsystem is intended to be used, since these are the examples the framework's own maintainers curate. Look to community UI libraries and tutorials when you want opinionated application architecture rather than API demonstration. Verify first that your toolchain matches the branch, Visual Studio 2026 with the .NET 10 SDK for main, or the release branches under Visual Studio 2022 for older targets, remember the msbuild-only solution for C++ samples, and unblock the ZIP before extracting if you download rather than clone.

Frequently asked questions

Official sources

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