Rapid XAML Toolkit: analysis and generation for XAML in Visual Studio

A tool that treats XAML as a language worth analysing

The Rapid XAML Toolkit is a collection of tools for making it easier to work with XAML in Visual Studio, across UWP, WPF, Xamarin.Forms, WinUI 3 and .NET MAUI. The framing of the project description is careful: a collection of tools, not a framework, and the toolkit explicitly says it will not include controls.

The headline capability is XAML analysis, described as being like Roslyn analyzers but for XAML. In editor, it identifies potential issues and offers Suggested Actions to fix them, which is the same loop a C# developer already has through Roslyn: a diagnostic appears, a code fix is attached, you apply it. The difference is that the target is markup rather than code, and markup in a large application is exactly where those errors hide.

The features are listed as five groups. In-editor analysis of your XAML to find and fix issues faster. Generation of XAML from your ViewModels. Enhancements to the editor window. Roslyn analyzers to help with code related to MVVM and XAML. And project and item templates to create new apps faster.

The last two matter more than they first appear. The Roslyn analyzers cover the C# side of an MVVM application, which is where the ViewModel to XAML generation actually comes from, so the toolkit spans both halves of the pattern rather than only the markup. The templates cover the initial project scaffold, which is where a generator that understands ViewModels can save the most time.

The readme states that Visual Studio 2022 support is coming soon, which dates the ambition in the readme relative to the current state of the extension.

Analysis that can run in CI, not only in the editor

The part of the analysis story that separates this from a linter built into the IDE is that it can be run outside Visual Studio.

You can create your own custom analyzers, and the analysis can be run as part of a build or CI process using a NuGet package named RapidXaml.BuildAnalysis. That changes what the tool is for. An editor-only diagnostic is a convenience for the developer at the keyboard, but a build step is a gate. A team can require that no new XAML issues reach the main branch, and can report them the same way it reports other static analysis failures.

The comparison to Roslyn Analyzers in the readme is therefore doing more work than it appears. Roslyn analyzers are a Microsoft concept precisely because they can be attached to the compiler and run in a build. The toolkit is making the same move for XAML, and the existence of a separate build analysis package is the evidence that it goes beyond the IDE.

The documentation structure supports this reading. There is a features page describing what the analysis can find, a separate page on custom analysis for people writing their own analyzers, a configuration page, and a getting started guide that the readme points to for installation rather than spelling out the steps itself. When a project has separate pages for custom analysis and for a configuration reference, it has a user base that intends to go past the defaults.

The repository layout backs that up too. There is a NuGet directory alongside the VSIX directory for the extension itself, a config directory, a Templates directory, a Rider directory, a docs directory with an Assets folder for the screenshots, plus a CHANGELOG, RELEASE_NOTES and a LICENSE.txt file.

ViewModel to XAML generation, with every output configurable

The generation feature turns ViewModels into XAML with a couple of clicks or a drag of the mouse, and the readme includes an animation of the drag and drop flow.

The important qualifier is that the generated XAML is based on common conventions but is highly configurable, with a configuration page documenting the options. That matters, because generated code that you then have to rewrite defeats the purpose. A generator whose output follows a convention you already use is worth having; a generator whose output follows a convention you do not use is a starting point you have to undo.

The principles section in the readme states the project philosophy, and it is worth reading because it explains the design decisions. Developers using XAML deserve the best tools possible. Doing something is better than doing nothing. Everything that is output should be configurable. C# and VB.NET are supported equally. The toolkit will not do things that Visual Studio can already do, without very good reason. The toolkit cannot generate the final XAML, because every app requires unique customisation. And the toolkit is focused specifically on tooling for working with XAML, so it will not include controls.

Three of those principles are doing real work. The rule that everything output should be configurable is what makes the generator usable inside an existing codebase rather than only for greenfield work. The admission that the generated XAML can never be final is an honest scoping of what the tool promises, and it sets expectations correctly, since view markup always ends up with app specific layout. And the explicit refusal to duplicate what Visual Studio already does is a good discipline for a project that could otherwise grow a feature list nobody wants.

C# and VB.NET being supported equally is worth noting too, since the generator reads your ViewModel code and has to understand the type system in front of it.

A Microsoft project that moved to one maintainer

The history section explains the provenance, and it explains the current state of the repository.

The Rapid XAML Toolkit was started as a sister project to Windows Template Studio, and it was originally created in partnership with Microsoft. That is why the GitHub URL github.com/microsoft/rapid-xaml-toolkit redirects to this repository. It is now primarily cared for by Matt Lacey.

That transition from a Microsoft partnership to a single maintainer is the main thing to weigh in an adoption decision, and the dates make it concrete. The published releases are v0.12 from 2021-05-17 and v0.11 from 2020-09-13, so the tagged history stops more than four years ago, while the last push to the repository was on 2026-04-15. Work is still landing on the branch, but there is no recent tag to point at and no release cadence in the tag list.

The extension itself is distributed through the Visual Studio Marketplace as MattLaceyLtd.RapidXamlToolkit, and the homepage in the project metadata is that marketplace listing, so the Marketplace rather than the GitHub releases is where you would get the current build. The repository also carries a Rider directory, which suggests work aimed at the other main .NET IDE, and a .404-links.yml file for handling moved links, which is what you would expect once a project has been renamed and moved.

The readme badge shows an MIT licence and the repository carries a LICENSE.txt file, though the licensing metadata for the project records a custom licence that GitHub cannot classify, so the terms are in that file rather than in a standard identifier.

Where the toolkit fits against doing it by hand

There are three realistic alternatives, and the principles in the readme are effectively a statement of where this one sits among them.

The first is doing nothing, which for many teams means writing the view markup by hand and fixing binding errors by running the app. The readme calls this doing nothing, and the comparison point is the Suggested Actions loop, which is a genuine productivity difference on a large XAML codebase where a wrong element name or a missing property is otherwise found at runtime.

The second is a general purpose code analysis tool applied to markup. There are XAML linters, and some editors have their own markup validation. The difference here is that the analysis is integrated with the Roslyn analyzers for the ViewModel side of the same application, so a mismatch between a property in the ViewModel and a binding in the XAML is one analysis pass rather than two tools with two configurations.

The third is a different kind of generation, either a template you maintain by hand or a scaffolding tool that generates a whole project structure. The toolkit deliberately does not replace Visual Studio's own project creation, on the stated principle that it will not do what Visual Studio can already do without very good reason. Its generation is narrower, taking a ViewModel and producing view markup for it, and it stops where the app specific layout begins.

That boundary is the trade. The toolkit does less than a full scaffolding tool and more than a linter, and the part of the value that is hardest to replicate is the CI integration, because a build analysis package for XAML is something you would otherwise have to write.

Editorial conclusion

Adopt the Rapid XAML Toolkit if you build XAML heavy applications in Visual Studio, especially .NET MAUI or WinUI 3, and you want analysis errors, suggested fixes and a starting point for view markup without hand writing the first pass. Do not adopt it if you are on Rider rather than Visual Studio, or if you need a maintained release stream, because the published versions stop at v0.12 from 2021 and the last push was on 2026-04-15. Before you commit, read the features and configuration pages, check the NuGet build analysis package if you want the same checks in CI, and confirm the extension is listed on the Visual Studio Marketplace for your Visual Studio version.

Frequently asked questions

Official sources

1. Issues
2. mrlacey/Rapid-XAML-Toolkit on GitHub
3. Project website
4. README
5. Releases