# CommunityToolkit/dotnet: what the .NET Community Toolkit actually ships > The .NET Community Toolkit is four NuGet packages from Microsoft: Common, Diagnostics, HighPerformance and Mvvm. The last push was on 2026-03-25, and the MVVM toolkit is the piece most teams come for. **CommunityToolkit/dotnet** — .NET Community Toolkit is a collection of helpers and APIs that work for all .NET developers and are agnostic of any specific UI platform. The toolkit is maintained and published by Microsoft, and part of the .NET Foundation. - Repository: https://github.com/CommunityToolkit/dotnet - Website: https://docs.microsoft.com/dotnet/communitytoolkit/?WT.mc_id=dotnet-0000-bramin - Stars: 3,756 · Forks: 401 - Language: C# - License: NOASSERTION - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/communitytoolkit-dotnet ## Four packages, one repository, and the audience each one targets This repository holds libraries that were originally developed as part of the Windows Community Toolkit, and the README is explicit that they are agnostic of any specific UI platform. That sentence is the whole pitch. Application developers get helpers that behave the same in WPF, MAUI, Uno Platform, UWP and plain console code; library authors get the same helpers without dragging a UI dependency into their package graph. The README breaks the repo into four NuGet packages. CommunityToolkit.Common is described as a set of helper APIs shared with the other CommunityToolkit libraries, so it is mostly a dependency rather than something you reference deliberately. CommunityToolkit.Diagnostics provides Guard and ThrowHelper for argument validation and error checking. CommunityToolkit.HighPerformance is the systems-oriented one: pooled buffer helpers, a string pool, the Memory2D and Span2D types that also support discontiguous regions, and bit shift helpers used in Paint.NET. CommunityToolkit.Mvvm is the MVVM library, described as the official successor of MvvmLight and used in the Microsoft Store. Who is this for, concretely? If you maintain a .NET app with a view model layer and you have been hand-writing INotifyPropertyChanged plumbing, the MVVM package is aimed at you. If you write libraries that validate arguments on every public entry point, Diagnostics is aimed at you. HighPerformance is aimed at people who already know where their allocations are and want lower-level primitives. If you want controls, navigation, or a dependency injection container, none of the four packages is that. ## How the toolkit is put together and what the source generator does The repository layout tells you the shape of the project before you open a single file. There is src/ and tests/ at the top level, a dotnet.slnx solution file, Directory.Build.props and Directory.Build.targets for shared MSBuild configuration, a global.json pinning the SDK, and a version.json. That is a standard modern .NET library layout, and it means the four packages are built from one solution with shared build settings rather than four independent repos. The MVVM package is the one where the mechanism matters most. It is a source generator: you annotate a field or a partial class, and the generator emits the property, the change notification and the command implementation at compile time. That is why the README calls it fast and modular. Nothing is resolved by reflection at runtime for the generated members, and the generated code is visible in your project after a build. The trade-off is that the generated code is not something you edit; you change the annotation and rebuild, and debugging steps through generated files. HighPerformance takes a different approach. Memory2D and Span2D exist because the built-in types model a single contiguous region. The toolkit's variants add support for discontiguous regions, which is what you need when a rectangular view over a larger buffer has gaps between rows. The string pool and pooled buffer helpers follow the same theme: reuse memory instead of allocating. These are opt-in primitives, not automatic optimizations, and the documentation is where you go to understand the ownership rules for anything pooled. Diagnostics is the simplest of the four. Guard and ThrowHelper centralize the throw statements for null checks and range checks, so validation code is one line instead of five and the throw sites are consistent across a codebase. ## Installing the packages and getting a first observable property working The README does not give a command-line install snippet. It points to the Getting Started page on Microsoft Learn and describes the Visual Studio route: Tools > NuGet Package Manager > Manage NuGet packages for solution, then search for one of the package names from the .NET Community Toolkit NuGet Packages table. The README states that NuGet is the standard package manager for .NET applications and that it is built into Visual Studio, so the package IDs to search for are the ones in the README's own table: CommunityToolkit.Common, CommunityToolkit.Diagnostics, CommunityToolkit.HighPerformance and CommunityToolkit.Mvvm. Once the package is restored, the package reference appears in your project. The README does not include a code sample, so the first real use is best taken from the API documentation the README links to, which is hosted on Microsoft Docs and the .NET API Browser. For the MVVM package the entry point is the aka.ms/mvvmtoolkit/docs link the README gives, and the README also points to a separate sample app repository at aka.ms/mvvmtoolkit/samples. The practical sequence is: reference the package, open the linked documentation for the type you need, and follow the sample app for a working end-to-end structure rather than inventing one. The README does not document a rollback path for generated members or for removing a package reference, so treat the package choice as something to verify against the API docs before you build on it. ## Where the toolkit stops: no controls, no container, no rollback story The clearest limitation is taxonomic. The README says these libraries are agnostic of any specific UI platform, and that is a constraint as much as a feature. There are no XAML controls here, no navigation service, no dialog abstractions. If your problem is that you need a data grid, this repository does not solve it, and the Windows Community Toolkit, which the README names as the origin of these libraries, is the place to look instead. The MVVM package also does not give you a dependency injection container. It gives you observable objects and commands. Wiring view models to services is your decision, and the toolkit does not take a position on it. Teams coming from a batteries-included framework will find that gap larger than they expect. The source generator has a real failure mode: it only augments partial types, and it emits code you cannot hand-edit. If a property name collides with something you wrote, the error surfaces at compile time in generated code, which is a less pleasant place to read an error than your own file. Nothing in the README describes a rollback or migration path for removing generated members later. HighPerformance is the wrong tool for most code. Pooled buffers and Span2D exist for measured allocation pressure. Introducing them into a code path that is not hot adds ownership rules and lifetime questions for no measurable gain, and the documentation is the only place those rules are written down. Diagnostics is similarly optional: if your codebase already has a consistent validation helper, adding Guard is churn. Finally, the release cadence is uneven. v8.4.0 is dated 2024-12-12, while v8.4.1 and v8.4.2 both landed on 2026-03-24 and 2026-03-25. The last push to the repository was on 2026-03-25. A year-long gap between minor releases is not a sign of abandonment, but it does mean you should not plan around frequent feature drops. ## CommunityToolkit.Mvvm against hand-written INotifyPropertyChanged and ReactiveUI The honest alternative for most teams is not another library. It is writing the plumbing yourself: a base class implementing INotifyPropertyChanged, a SetProperty helper, and manual ICommand implementations. That approach has zero dependencies, no generator, and nothing to learn. It also means every property is four lines of boilerplate and every command is a small class, and the compiler will not catch a missed PropertyChanged call. The MVVM toolkit replaces that boilerplate with annotations and generated members, and the README positions it as the official successor of MvvmLight, so teams migrating from MvvmLight have a documented destination rather than a rewrite. ReactiveUI is the other real comparison, and the difference is philosophical rather than cosmetic. ReactiveUI models view model state as observable streams and composes them with LINQ-style operators; the MVVM toolkit models state as properties on an object with change notification. If your application's complexity comes from combining and debouncing streams of events, ReactiveUI's model fits that shape. If it comes from a large number of simple properties and commands, the toolkit's model is less machinery. The two are not mutually exclusive in principle, but mixing them in one view model layer means two mental models for the same state, which is a cost worth naming before you start. For the other three packages the alternatives are the BCL itself. Argument validation can be written inline; pooled buffers can come from ArrayPool directly. The toolkit's value there is consistency and the extra types like Span2D that the BCL does not offer, not a capability you cannot otherwise reach. ## Maintenance, licence and what an upgrade actually costs Maintenance signals from the repository are mixed and worth reading carefully. The repository is not archived. The last push was on 2026-03-25, and the most recent releases, v8.4.1 and v8.4.2, are dated 2026-03-24 and 2026-03-25. The README states the toolkit is maintained and published by Microsoft and is part of the .NET Foundation, and it names the Microsoft Store as a first-party consumer. That is a strong ownership signal. The counterweight is the release history: v8.4.0 is dated 2024-12-12, so the gap to the next release was over a year. Upgrade cost depends on which package you take. Common and Diagnostics are small helper surfaces, and moving between minor versions is unlikely to require code changes. The MVVM package is the one to watch, because the generated members are part of your public surface: renaming a field changes a property name that XAML bindings reference, and the compiler will not always catch a binding that no longer resolves. If you use the source generator heavily, budget time for a binding audit when you move major versions, not just a package restore. HighPerformance carries the usual risk of low-level primitives: an upgrade can change behaviour around pooling or span lifetimes, and those bugs show up under load rather than in tests. On licensing, GitHub reports the repository licence as NOASSERTION, which means the platform could not classify the file automatically. The repository root contains License.md and ThirdPartyNotices.txt, and those are the files to read. This article is not legal advice and does not interpret them; the practical point is that you should not treat the GitHub label as the answer, especially if you redistribute the packages or ship them inside a product. ## Conclusion Adopt CommunityToolkit.Mvvm if you are writing a WPF, MAUI, Uno or UWP app and want observable properties and commands without a framework lock-in; adopt Diagnostics and HighPerformance only where argument validation or pooled buffers are already a measured concern. Do not adopt it expecting a UI control library, a DI container, or anything that replaces a full application framework, and do not expect the repo to move quickly: the last push was on 2026-03-25 and v8.4.0 sat between 2024-12-12 and the 8.4.1 release on 2026-03-24. Before committing, read License.md and ThirdPartyNotices.txt in the repository root, since GitHub reports the licence as NOASSERTION, and check the NuGet page for each individual package you plan to reference. ## FAQ ### What is the .NET Community Toolkit used for? It provides four helper libraries that work across UI frameworks: Common for shared helpers, Diagnostics for Guard and ThrowHelper argument validation, HighPerformance for pooled buffers, a string pool, Memory2D and Span2D, and Mvvm for observable properties and commands. The README states they are agnostic of any specific UI platform and are used in first-party Microsoft apps such as the Microsoft Store. ### How do I install the .NET Community Toolkit? The README points to the Getting Started page on Microsoft Learn and describes the Visual Studio route through Tools > NuGet Package Manager > Manage NuGet packages for solution, searching for a package name from the NuGet Packages table. The README states that NuGet is the standard package manager for .NET applications and is built into Visual Studio, and the package IDs to search for are CommunityToolkit.Common, CommunityToolkit.Diagnostics, CommunityToolkit.HighPerformance and CommunityToolkit.Mvvm. ### Is the .NET Community Toolkit the same as the Windows Community Toolkit? No. The README says this repository contains libraries originally developed as part of the Windows Community Toolkit, but these are UI-platform-agnostic and work everywhere, while the Windows Community Toolkit remains the place for Windows-specific components. The toolkit is maintained and published by Microsoft and is part of the .NET Foundation. ### Does CommunityToolkit.Mvvm replace MvvmLight? The README describes CommunityToolkit.Mvvm as the official successor of MvvmLight. It is a source-generated MVVM library, so observable properties and commands are produced at compile time from annotations rather than resolved by reflection at runtime. ### Is the .NET Community Toolkit actively developed? The repository is not archived and the last push was on 2026-03-25, with v8.4.1 and v8.4.2 released on 2026-03-24 and 2026-03-25. Note that v8.4.0 is dated 2024-12-12, so the gap between minor releases has been long, and the README points to the milestones page for what is planned next. ## Sources - [CommunityToolkit/dotnet on GitHub](https://github.com/CommunityToolkit/dotnet) - [Issues](https://github.com/CommunityToolkit/dotnet/issues) - [Project website](https://docs.microsoft.com/dotnet/communitytoolkit/?WT.mc_id=dotnet-0000-bramin) - [README](https://github.com/CommunityToolkit/dotnet/blob/main/README.md) - [Releases](https://github.com/CommunityToolkit/dotnet/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/communitytoolkit-dotnet