# The Windows Community Toolkit fills the gaps WinUI leaves open > This is a set of controls, helpers and extensions for WinUI 2, WinUI 3 and Uno Platform developers, shipped as two families of NuGet packages, one per stack. It carries a custom licence rather than a standard one, and its stated second principle is that any feature the Windows SDK eventually ships will be deprecated here. **CommunityToolkit/Windows** — Collection of controls, helpers and extension for WinUI 2, WinUI 3, and Uno Platform developers. Simplifies and demonstrates common developer tasks building experiences for Windows with .NET. - Repository: https://github.com/CommunityToolkit/Windows - Website: https://aka.ms/windowstoolkitdocs - Stars: 1,079 · Forks: 169 - Language: C# - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/communitytoolkit-windows ## A component library for three XAML stacks at once The Windows Community Toolkit is a collection of controls, helpers and extensions for WinUI 2, WinUI 3 and Uno Platform developers, and the project describes its purpose as simplifying and demonstrating common developer tasks when building experiences for Windows with .NET. The three target stacks explain the shape of the library. WinUI 2 runs on UWP, WinUI 3 runs on the Windows App SDK, and Uno Platform runs the same XAML on other platforms. A component that can live in all three is worth more than a component written for one, because the alternative for a company with a Windows app and a mobile app is two implementations of the same control. The audience is application developers rather than framework authors. The documentation link at the top of the project page points at the Getting Started page, and the project asks you to read it for detailed information about using the Toolkit in your app, which is a reminder that this is a library with a documented API surface and a versioned package, not a folder of sample code. There is a second audience in the repository itself. The contribution section points people with ideas at the Windows Community Toolkit Labs repository, and the issues list has a help wanted label to look through. The stated contribution surface is wide: new features through Labs, improvements to docs and samples, and new tests, with the project saying that even those smaller contributions help. A wiki page covers the guidelines in general. The project is supported by the .NET Foundation and has adopted the Contributor Covenant code of conduct, and the discussion board is linked for engagement. ## Two package families, because the underlying stack differs The packaging detail that matters most to a consumer is that there are now two sets of packages for each component, and the split is by runtime rather than by name. CommunityToolkit.Uwp.* is for UWP and WinUI 2, or for Uno.UI. CommunityToolkit.WinUI.* is for the Windows App SDK and WinUI 3, or for Uno.WinUI. So the same component ships twice under different package identifiers, once for the older UWP stack and once for the Windows App SDK. That is a consequence of the platform split between WinUI 2 and WinUI 3, which are different frameworks with different packaging and different deployment models, and it is a real cost. A project that targets both has to reference two packages, and a library author who wants to support both has to build two. The Uno naming in the same line is worth noting too, since Uno.UI and Uno.WinUI are the two Uno flavours corresponding to the two stacks. The distribution route is NuGet, the standard package manager for .NET applications, which the project notes is built into Visual Studio. The instruction for the interactive route is concrete: open the solution in Visual Studio, choose the Tools menu, then NuGet Package Manager, then Manage NuGet packages for solution. The repository layout matches a large multi target library. There is a components directory for the code, a catalog directory, a docs directory, tools and tooling directories, a .devcontainer directory for a containerised development environment, a global.json pinning the SDK, Directory.Build.props and Directory.Build.targets for shared build settings, a nuget.config, and a settings.xamlstyler with an ApplyXamlStyling.ps1 script, which is how the XAML files are kept consistently formatted. ## Cloning needs submodules, and the build needs SlnGen The build instructions are specific and have one trap that catches newcomers. The trap is the tooling. It lives in a separate repository, Tooling-Windows-Submodule, and is wired into this repository as a git submodule, so the clone has to bring it along: ```shell git clone --recurse-submodules https://github.com/CommunityToolkit/Windows.git ``` The same applies to later pulls, since the documentation says to use --recurse-submodules when cloning or pulling for the first time. Then there is the environment. The Toolkit requires Visual Studio 2022 or later to build and Windows 10 or later to execute. The required Visual Studio components are listed: Windows application development, .NET desktop development, the Windows 10 SDK version 2004 (10.0.19041.0), and Windows 10 21H1 (build 19043) or greater. There is a link to the Windows App SDK installation instructions for people building a WinUI app for the first time. The build itself has two steps. First, run dotnet tool restore from the project root to install SlnGen, the tool that generates the solution files. Then run the build scripts, either from the Developer Command Prompt for Visual Studio or from elsewhere once MSBuild.exe is on your PATH: ```shell dotnet tool restore ``` The .vsconfig file in the repository root is the Visual Studio component manifest, which is the file a contributor would edit to declare the workloads they need installed, and the .config and .devcontainer directories support the same setup in a container or in a plain configuration directory. There is a gallery application in the Microsoft Store, the Windows Community Toolkit Gallery, which the project offers as a way to see the Toolkit in action before you write any code, and a large set of images in the docs folder showing each component. ## Three principles, and one of them is about deletion The principles the project publishes are short and, for the second one, unusual. The first is that the toolkit will provide features that are needed for a wide array of developers, are easy to use, and are maintainable. That is a statement about scope, and it is the one that explains why the library is a set of general purpose components rather than a showcase of exotic controls. The second is the interesting one: as soon as a comparable feature is available in the Windows SDK for Windows, it will be marked as deprecated. The toolkit is explicitly designed to be temporary in the places where the platform catches up. That is an unusual and rather respectable stance. Many component libraries accumulate features for years after the platform has shipped a better version, and the users are the ones who notice. Here, deprecation is scheduled by policy. The third is that issues will be fixed forward and the toolkit will stay up to date on top of WinUI 2 and 3 updates, supporting the minimum OS level that those stacks also support. Two consequences follow. First, forward only means no long term support branch: when a version is dropped, it is dropped, and you upgrade or you fork. Second, the minimum OS level is not the toolkit's choice, so a component may require a newer Windows than you would like, and that floor moves with the platform. The project also publishes migration notes for anyone coming from a pre 8.x version, which tells you that 8.x was a breaking change and that the current major line is 8. ## Version 8 with previews, and a licence you have to read The release pattern is a stable line with previews ahead of it. The tagged releases in the list are v8.2.251219 from 2025-12-20, v8.3.260211-preview1 from 2026-02-11 and v8.3.260402-preview2 from 2026-04-02. The version strings carry the date of the build, and the two most recent tags are explicitly marked as pre-releases. The repository is not archived and the last push was on 2026-10-16, several months after the last tagged preview. For a component library, that gap is the thing to keep an eye on, because it usually means the default branch has moved on from the newest published package. The build of the toolkit itself is a bigger commitment than most consumers make, since it needs Visual Studio 2022, specific SDKs and a submodule, so most people consume it as a NuGet package rather than building it. The licence is the item that needs a decision rather than a glance. The licence field is set to Other, a custom licence that GitHub cannot classify, and the file at the root is License.md rather than one of the standard texts. The toolkit is presented as a.NET Foundation project, which is a good sign, but the actual terms are in that file, and a commercial team whose legal process expects a recognised licence will need to read it rather than infer the terms from the foundation affiliation. The.NET Foundation does not put every project under a single licence, and this project states its own. On upgrade cost, the third principle has the last word. If a WinUI update drops support for an OS level you still need, the toolkit follows the platform, so your minimum supported Windows version can move without the toolkit changing anything. That is a predictable upgrade, but it is an upgrade, and it should be part of your planning. ## Where the toolkit is the wrong choice There are clear boundaries, and they are worth stating before you install anything. The first is the framework. Everything here is built on WinUI 2, WinUI 3 or Uno Platform. If your desktop application is WPF, Windows Forms, or something else entirely, none of these components apply, and the cost of the dependency is zero value. Uno Platform is the escape route if you want the components to reach beyond Windows, but it is still a XAML stack, so the boundary is the toolkit, not the language. The second is that the toolkit is a library of pieces, not a design system. It will not make your application look coherent. A colour picker and a rating control do not decide your spacing, your typography or your motion, and the gallery app is there to show what the components look like rather than to define a house style. The third is the deprecation policy, which is a feature and a limitation at once. If you adopt a component that the Windows SDK later ships, you will be told to move to the platform version, and that migration is on your schedule, not the toolkit's. Teams that want to settle on a component and keep it for years should read the principles before choosing. The fourth is the version floor. The components follow the minimum OS level of the underlying WinUI versions, and they require Visual Studio 2022 and the Windows 10 SDK 2004 to build from source. A team on an older build toolchain can still consume the NuGet packages, but a team that intends to build and modify the toolkit itself needs to upgrade its environment first. The real alternative is writing the component yourself, or copying one from another project. That is the honest comparison, because the toolkit is not doing anything you could not do with a control that derives from the same base class. The reason to take the package instead is the maintenance: the deprecation policy means somebody else watches the platform, and the package version does the same work on WinUI 2, WinUI 3 and Uno without three implementations on your side. ## Conclusion The Windows Community Toolkit is worth adopting if you are building a Windows app on WinUI 2, WinUI 3 or Uno Platform and you would rather not write the same control, colour picker, animation or storage helper for every project. It is the wrong choice if your app is WPF, WPF-era or a web stack, since nothing here applies, and it is a poor fit if you need features the Windows SDK already ships. Before you add a package, read License.md, because the repository licence is a custom one that GitHub cannot classify, check the Getting Started page for the current component list rather than this README, and plan for the version line you are on, since the newest stable release is v8.2.251219 from 2025-12-20 and the two most recent tags are previews from February and April 2026 while the last push was on 2026-10-16. ## FAQ ### What is the Windows Community Toolkit and who is it for? It is a collection of controls, helpers and extensions for WinUI 2, WinUI 3 and Uno Platform developers, built to simplify common Windows app development tasks in .NET. The project is supported by the .NET Foundation and its components are consumed as NuGet packages from Visual Studio. ### What is the difference between CommunityToolkit.Uwp and CommunityToolkit.WinUI packages? CommunityToolkit.Uwp.* is for UWP with WinUI 2 or Uno.UI, and CommunityToolkit.WinUI.* is for the Windows App SDK with WinUI 3 or Uno.WinUI. Each component ships in both families because the two underlying stacks are different frameworks. ### How do I clone and build the Windows Community Toolkit from source? Clone with git clone --recurse-submodules https://github.com/CommunityToolkit/Windows.git, because the tooling lives in a submodule. Then run dotnet tool restore from the project root to install SlnGen, and run the build scripts from the Developer Command Prompt for Visual Studio or with MSBuild.exe on your PATH. Building requires Visual Studio 2022 or later. ### What happens to a Toolkit component when the Windows SDK ships the same feature? It is marked as deprecated, according to the second principle the project publishes. The toolkit is meant to be temporary where the platform catches up, and it fixes issues forward only while staying current with WinUI 2 and 3 updates. ### What licence does the Windows Community Toolkit use? It is a custom licence rather than a standard one, and GitHub cannot classify it, so the terms are in the License.md file at the repository root. Read that rather than assuming MIT or Apache terms from the .NET Foundation affiliation. ## Sources - [CommunityToolkit/Windows on GitHub](https://github.com/CommunityToolkit/Windows) - [Issues](https://github.com/CommunityToolkit/Windows/issues) - [Project website](https://aka.ms/windowstoolkitdocs) - [README](https://github.com/CommunityToolkit/Windows/blob/main/README.md) - [Releases](https://github.com/CommunityToolkit/Windows/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/communitytoolkit-windows