# Caliburn.Micro: Convention-Based MVVM for WPF, Avalonia and WinUI

> Caliburn.Micro binds views to view models by naming convention rather than by XAML markup. It is a good fit for teams that want testable XAML apps and are willing to accept a container of its own and a documentation set that lives mostly in samples.

**Caliburn-Micro/Caliburn.Micro** — A small, yet powerful framework, designed for building applications across all XAML platforms. Its strong support for MV* patterns will enable you to build your solution quickly, without the need to sacrifice code quality or testability.

- Repository: https://github.com/Caliburn-Micro/Caliburn.Micro
- Website: http://caliburnmicro.com/
- Stars: 2,865 · Forks: 768
- Language: C#
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/caliburn-micro-caliburn-micro

## The problem Caliburn.Micro removes from XAML

In plain WPF, Avalonia or WinUI, a view and its view model are connected by hand. You set a DataContext, write Binding expressions with a Path for every property and command, and repeat that work for each screen. Caliburn.Micro replaces most of that with naming rules. The repository describes itself as "a small, yet powerful framework, designed for building applications across all XAML platforms", with "strong support for MVVM and other proven UI patterns". The audience is C# and VB.NET developers building desktop or cross-platform XAML applications who want the view model to stay free of view concerns and therefore testable without a UI thread. The topics listed on the repository span wpf, avalonia-ui, winui3, dotnet-maui, xamarin-forms and uwp, so the project is aimed at people who target more than one XAML stack and would rather not rewrite their binding layer per platform.

## How the convention engine and the container work together

Two mechanisms do the work. The first is the view locator: a view model named ShellViewModel is matched to a view named ShellView, and the framework sets the DataContext for you. The second is the binding convention: a control named Save on the view is matched to a Save method or a Save property on the view model, and a control named CustomerName is matched to a CustomerName property. That is why so little XAML is needed in a Caliburn.Micro screen. Underneath sits an IoC container that the framework uses to construct view models and resolve their dependencies. The README points to a separate Caliburn.Micro.Core package, described as "the Standard Class Library portion of Caliburn.Micro", with the platform-specific adapters in the main Caliburn.Micro package. That split matters: the core holds the conventions and the container, and the platform packages supply the adapters that connect it to WPF, Avalonia, WinUI or MAUI. The repository also ships a samples directory with setup, features, scenarios and tutorials subfolders, which is where the intended composition of the bootstrapper is demonstrated.

## Installing Caliburn.Micro and wiring a first screen

Packages come from NuGet. The README lists Caliburn.Micro.Core for the class library portion and Caliburn.Micro for the platform adapters, and states that support for Avalonia, MAUI and WinUI is published on GitHub Packages as Caliburn.Micro.Avalonia, Caliburn.Micro.Maui and Caliburn.Micro.WinUI. Install the platform package for your target, which pulls in the core.

```bash
dotnet add package Caliburn.Micro
dotnet add package Caliburn.Micro.Avalonia
```

The first command adds the platform-specific adapters, the second adds Avalonia support when that is your UI stack. The project does not publish a single install command that covers every platform, so pick the package that matches your target rather than adding all of them.

A view model is an ordinary class. The convention engine finds it by name, so a class called ShellViewModel is paired with a view called ShellView, and a property called CustomerName is bound to a control of the same name without a Binding expression.

```csharp
public class ShellViewModel
{
    public string CustomerName { get; set; }

    public void Save()
    {
    }
}
```

The Save method is invoked when a control named Save is activated, and CustomerName is read and written by a control of that name. The bootstrapper that connects the container to the application is not shown in the README; the samples/setup/ folder in the repository is where that composition is demonstrated, so read it before writing your own. For questions that are not bugs, the README directs readers to Stack Overflow under the caliburn.micro tag.

## Where the conventions stop being convenient

Convention over configuration is a trade. When a control is not bound, nothing fails loudly. The name simply does not match, and you get an inert control with no error at the point of definition, which is harder to diagnose than a Binding path that a XAML compiler or a debug trace can report. Teams that rely on explicit bindings for discoverability will find the indirection uncomfortable. The second cost is the container. Because the framework resolves view models through its own IoC container, the container becomes part of your application's architecture rather than a library you chose independently. If your project already standardises on another container, adopting Caliburn.Micro means either working with its container or accepting an adapter layer. Finally, the README is thin. It lists packages, a questions channel and a sponsorship note, and points at the samples directory; it does not document the bootstrapper, the convention rules or upgrade steps in prose. The samples are the documentation, and that is a real constraint when onboarding someone who has never seen the framework.

## Caliburn.Micro against Prism and the Community Toolkit

Prism also targets XAML applications and also provides MVVM support, but its centre of gravity is modularity: regions, module catalogues and navigation between them. Caliburn.Micro's centre of gravity is the naming convention between view and view model. If your application is a shell with independently developed modules that get composed at runtime, Prism's model is closer to the problem. If your application is a set of screens that need predictable, testable view models with as little XAML as possible, the convention engine is the more direct answer. The Community Toolkit MVVM approach is lighter still: it supplies source-generated observable properties and relay commands, and leaves composition, view location and container choice to you. Caliburn.Micro gives you those pieces already assembled, at the cost of adopting its assembly. The honest summary is that the toolkit is a set of primitives, Prism is a modularity framework, and Caliburn.Micro is a convention framework.

## Maintenance, licence and what an upgrade costs

The repository is not archived, and the last push was on 2026-08-28, so work is ongoing. The most recent release listed is 5.0.258 from 2025-10-14, following 4.0.230 in December 2024 and 4.0.222 in September 2022. That spacing is worth noting: the gap between 4.0.222 and 4.0.230 is roughly two years, so a major-version upgrade is not something you should schedule casually. The project is licensed under MIT, which permits commercial and closed-source use and requires that the licence and copyright notice be preserved; the licence text is in License.txt at the repository root. This is a description of the licence terms, not legal advice. The upgrade cost is mostly in the conventions and the bootstrapper rather than in the packages: because view-to-view-model wiring is implicit, a change in convention behaviour can surface as a screen that stops responding rather than as a compile error, which makes a test suite over the view models the practical safety net.

## Conclusion

Adopt Caliburn.Micro if you are building a WPF, Avalonia, WinUI or MAUI application and want view-to-view-model wiring that does not live in XAML, and you accept that its container and conventions become part of your architecture. Do not adopt it if you want the smallest possible dependency surface, or if you need documentation that covers every feature in prose rather than in the samples folder. Before committing, verify that the platform package you need exists on NuGet for your target framework, read samples/setup/ and samples/features/ to see how the bootstrapper is composed, and confirm that your team is comfortable with the container resolving types by convention rather than by explicit registration.

## FAQ

### What is Caliburn.Micro?

It is a framework for building applications across XAML platforms, described in its README as small but powerful, with strong support for MVVM and other proven UI patterns. It connects views to view models by naming convention and ships a core library plus platform-specific adapter packages.

### Is Caliburn.Micro dead?

The repository is not archived and the last push was on 2026-08-28, so it is not abandoned. The release history is uneven, with 4.0.222 in September 2022, 4.0.230 in December 2024 and 5.0.258 in October 2025, so plan upgrades around that cadence rather than expecting frequent releases.

### How does Caliburn.Micro compare with Prism?

Both target XAML applications and both support MVVM. Prism is built around modularity with regions and module catalogues, while Caliburn.Micro is built around the naming convention between a view and its view model, so the choice depends on whether your main problem is composing modules or avoiding binding markup.

### How does Caliburn.Micro compare with the Community Toolkit MVVM?

The Community Toolkit supplies primitives such as observable properties and relay commands and leaves composition and view location to you. Caliburn.Micro assembles those concerns for you through its convention engine and its own IoC container, which is more complete but also a larger commitment.

## Sources

- [Caliburn-Micro/Caliburn.Micro on GitHub](https://github.com/Caliburn-Micro/Caliburn.Micro)
- [License: MIT](https://github.com/Caliburn-Micro/Caliburn.Micro/blob/master/LICENSE)
- [Project website](http://caliburnmicro.com/)
- [README](https://github.com/Caliburn-Micro/Caliburn.Micro/blob/master/README.md)
- [Releases](https://github.com/Caliburn-Micro/Caliburn.Micro/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/caliburn-micro-caliburn-micro