# XAML Behaviors attaches interactivity to XAML elements declaratively > Microsoft's XAML Behaviors package adds reusable interactivity to UWP and WinUI XAML without code-behind, by attaching behaviors, triggers and actions in markup. It is a managed-only, MIT licensed library whose releases lag behind the platform it targets. **microsoft/XamlBehaviors** — This is the official home for WinUI/UWP XAML Behaviors on GitHub. - Repository: https://github.com/microsoft/XamlBehaviors - Stars: 793 · Forks: 121 - Language: C# - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/microsoft-xamlbehaviors ## Interactivity in XAML without a code-behind file XAML Behaviors is Microsoft's library for adding common, reusable interactivity to Windows UWP applications with minimal code. The repository describes itself as the official home for WinUI and UWP XAML Behaviors on GitHub. The problem it addresses is specific to XAML. On a desktop framework you attach a click handler and write the method; in a XAML application, that pushes logic into a code-behind file that the markup designer cannot see and that reviewers have to open separately. Behaviors move that wiring into the markup itself, so a Button can carry the description of what happens when it is clicked without a matching .cs file. That matters most where behaviour repeats. A control template reused across a page, a dialog and a flyout needs its interaction defined once. With behaviors, the definition travels with the template rather than being copied into each page's code-behind. Two constraints are stated plainly in the README. The library is available for managed applications only, and use is governed by the MIT License. The managed-only limitation rules it out for native C++ XAML projects, which is a real constraint given how common native UWP still was in the platform's early years. The audience is therefore XAML developers on the Windows stack: teams maintaining UWP apps, or WinUI apps, who want declarative interactions without committing to a full framework for the problem. ## Behaviors, triggers and actions form one attached-property model The API in the README's snippet is small and worth reading closely, because the whole model is visible in it. The example attaches an Interaction.Behaviors collection to a Button, and inside it an EventTriggerBehavior with EventName set to Click, which in turn contains a ChangePropertyAction targeting PropertyName Background and setting a SolidColorBrush of Red. Three roles appear. The behavior is the object attached to an element. The trigger decides when something happens, here an event named Click on the element the behavior is attached to. The action carries out the effect, here changing a property. Because the action is a dependency property whose value is set declaratively, no code-behind is needed to repaint the button. The namespace is declared on the element itself with xmlns:Interactivity="using:Microsoft.Xaml.Interactivity", which tells you that the entry point is a namespace named Microsoft.Xaml.Interactivity even though the product is called XAML Behaviors. What the sample does not show is the composition surface. Triggers and actions are the visible parts of a model in which the trigger watches a condition and the action responds, and the library exists so that you can write your own behavior and reuse it. The repository has a tests directory and a NuGet_Documentation directory, and the wiki is the documented place for that API surface. The design trades runtime flexibility for declarative clarity. There is no dynamic binding of a behavior to arbitrary code, so a behavior cannot be swapped at runtime the way a command can. ## Adding the NuGet package and attaching a behavior Getting it into a project is a NuGet package, listed in the README under the Managed variant, Microsoft.Xaml.Behaviors.Uwp.Managed on nuget.org. The source code is the repository itself, and the wiki documents installing Visual Studio, adding the package to a project and starting to use the API. A first use means adding the namespace to a page and attaching a behavior to an element. The README's snippet is the whole example: ```xml ``` Two details are easy to get wrong. The behaviors collection is an attached property, so it lives inside an Interactivity-prefixed element rather than as a plain attribute on the Button. And the action's target value is itself a property element, so the brush goes inside ChangePropertyAction.Value rather than in an attribute. The repository also ships a samples directory with a CS sample, which the README links alongside the wiki, the changelog and a Gitter chat room. The samples are the faster way to see a behavior that reacts to something other than a click, since the README example is deliberately minimal. ## Building the packages with nuget restore and msbuild Building from source has explicit prerequisites: Visual Studio 2022 version 17.12 or newer with the Universal Windows Tools workload, and the Multilingual App Toolkit. The repository is cloned from within Visual Studio through the Team Explorer view, using the repository URL. The build expects nuget.exe to be available on PATH. From Visual Studio, you open the BehaviorsSDKManaged.sln solution, set the build configuration to Release and build it with the right-click Build action or by pressing F6. From the Visual Studio Developer Command prompt, the equivalent is two commands: ```bash nuget restore src\BehaviorsSDKManaged\BehaviorsSDKManaged.sln msbuild -t:build src\BehaviorsSDKManaged\BehaviorsSDKManaged.sln /p:Configuration=Release ``` The pack step is what produces the NuGet artefacts, and it is done per platform because there are two. For UWP: ```bash msbuild /t:pack src\BehaviorsSDKManaged\Microsoft.Xaml.Interactivity.Uwp\Microsoft.Xaml.Interactivity.Uwp.csproj /p:Configuration=Release ``` and for WinUI the same command against the WinUI project file. Both accept an optional /p:TimestampPackage=true switch to include a timestamp in the NuGet package version. The two-step restore-then-build sequence and the reliance on a Windows-only toolchain mean this is not a cross-platform build. A Linux CI agent cannot produce the package without Windows and the Visual Studio build tools, which is a constraint worth knowing before you set up a pipeline. ## One solution, two packages, one supported platform family The solution directory src\BehaviorsSDKManaged contains a project per target: Microsoft.Xaml.Interactivity.Uwp and Microsoft.Xaml.Interactivity.WinUI. Both are built from the same managed core, and the difference is which XAML framework the package binds to. That structure tells you the scope of the project, and the scope is narrower than the Windows application world at large. The README describes the library as targeting Windows UWP applications, and the repository describes itself as the home for WinUI and UWP XAML Behaviors. There is no package listed for WinUI 3, and the samples directory contains a CS sample rather than a mixed set of targets. The build status table lists one row, Managed, which is the only platform variant the project builds. Combined with the README's statement that the library is available for managed applications only, that sets two hard boundaries: no native C++ XAML support, and no targets beyond the UWP and WinUI frameworks named in the repository. Repository metadata reinforces that this is a Microsoft-operated project rather than a community one. The tree includes a NOTICE.txt, a SECURITY.md, azure-pipelines for the build, scripts, a key directory, es-metadata.yml and a .vsconfig for editor tooling. The pipeline definition is the piece to look at if you want to know how the released packages are produced, since it is the only place the build recipe is automated. ## XAML Behaviors against the command pattern in a view model The real alternative for interaction logic in a XAML application is the view model command. Instead of describing what happens when a control is clicked, the view model exposes an ICommand, the button binds to it, and the code lives in a class the markup designer can reason about. This is the pattern behind most structured XAML applications, and it is not a competitor to behaviors so much as the approach behaviors sit beside. The difference in approach is where the behaviour lives and when it is decided. A command is resolved at runtime through binding, so the same button can invoke different logic depending on the view model, and the logic is unit testable without a UI at all. A behavior is attached in markup, so the interaction is part of the view definition: it travels with a control template, and it is not swappable without editing the markup. That makes each one wrong for a different situation. Behaviors earn their place where the interaction belongs to the visual, such as a template that changes an element's appearance when it is selected, and where repeating the logic in several code-behind files would be duplication. Commands earn their place where the interaction is application logic, such as submitting a form, and where the logic must be testable and reusable across views. A third option, plain event handlers in code-behind, needs no package at all. The library exists to remove that option for the cases where it is the right one, not to forbid it. ## MIT licence and a release history with a gap in it XAML Behaviors is MIT licensed, with the licence referenced from the README and the repository carrying a LICENSE file and a NOTICE.txt. The MIT terms mean you can take the source, modify it, ship it inside a commercial application and even close-source your own product without owing anything beyond keeping the notice. The release history deserves a closer look, because it shows the project's rhythm. Version 3.0.1 was published on 2026-01-14, version 3.0.0 Preview 1 on 2024-12-04, and the previous line, WinUI Behaviors v2.0.9, on 2022-09-29. Between the 2.x and 3.0 lines there is a gap of more than two years, which tells you that the 2.x line stood still for a long stretch before the 3.0 preview arrived. The repository is not archived and the last push was on 2026-10-16, so work continues in the tree even though the tagged releases are infrequent. For a consumer of the NuGet package that means an upgrade arrives rarely and the version you adopt may be a year old. For a contributor it means the review queue is likely quiet and the wiki is the main reference. The version numbering also carries a naming inconsistency worth remembering when you search documentation: the 2.x releases were published under the name WinUI Behaviors, while the repository and the 3.x line use XAML Behaviors. An upgrade path is therefore simple in the mechanical sense, since the package is a single reference in a project file, and more careful in the practical sense, since a jump across the 3.0 preview boundary is where you would check the changelog in the wiki first. ## Conclusion Adopt XAML Behaviors when you maintain a UWP or WinUI application and want reusable interactions declared in markup rather than scattered across event handlers, especially where the same visual behaviour repeats across templates. Do not reach for it in a WinUI 3 or MAUI codebase that the repository does not target, and do not treat it as a replacement for a view model command layer. Verify first which of the two packages your project needs, UWP or WinUI, then confirm your Visual Studio and Multilingual App Toolkit setup can restore the solution before expecting a clean local build. The last push was on 2026-10-16 and version 3.0.1 was released on 2026-01-14. ## FAQ ### What is XAML Behaviors used for? It adds reusable interactivity to UWP and WinUI XAML elements with minimal code, by attaching behaviors, triggers and actions in markup instead of writing event handlers in code-behind. The README's example attaches an EventTriggerBehavior on Click to a ChangePropertyAction that sets a red brush. ### How do I install XAML Behaviors in a project? Add the Microsoft.Xaml.Behaviors.Uwp.Managed NuGet package to the project. The wiki explains how to install Visual Studio, add the package and start using the API, and the repository also ships a samples directory with a CS sample. ### How do I build the NuGet packages from source? You need Visual Studio 2022 17.12 or newer with the Universal Windows Tools and the Multilingual App Toolkit, plus nuget.exe on PATH. Run nuget restore on src\BehaviorsSDKManaged\BehaviorsSDKManaged.sln, build it with msbuild, then run msbuild /t:pack against the UWP or WinUI project file. ### Does XAML Behaviors support native C++ UWP apps? No. The README states that XAML Behaviors is available for managed applications only, and the build status table lists a single Managed platform. ### What licence is XAML Behaviors released under? MIT. The README states that use of XAML Behaviors is governed by the MIT License, with the repository carrying a LICENSE file and a NOTICE.txt. Version 3.0.1 was released on 2026-01-14 and the last push was on 2026-10-16. ## Sources - [Issues](https://github.com/microsoft/XamlBehaviors/issues) - [License: MIT](https://github.com/microsoft/XamlBehaviors/blob/main/LICENSE) - [microsoft/XamlBehaviors on GitHub](https://github.com/microsoft/XamlBehaviors) - [README](https://github.com/microsoft/XamlBehaviors/blob/main/README.md) - [Releases](https://github.com/microsoft/XamlBehaviors/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-xamlbehaviors