Camelotia is a file manager that exists to prove ReactiveUI works on five UI stacks

A file manager built to be a test bed, not a product

Camelotia is a sample cross-platform application built with reactive extensions, ReactiveUI, and modern .NET UI frameworks. The description makes its purpose explicit: it is a file manager for cloud storage providers and local file systems, and it demonstrates reactive MVVM architecture, testable view models and shared code across desktop UI frameworks.

That framing is the most important fact about the project, because it changes what you can reasonably expect from it. A sample application is judged on whether it demonstrates the pattern clearly, and on whether the layers are separable enough to be copied. It is not judged on whether it syncs a terabyte of files, and it does not carry the credential handling or the error recovery you would want from a tool you trust with your files.

The coverage is wide, which is the point of the exercise. Camelotia currently supports Yandex Disk, Google Drive, VK Documents, GitHub, FTP, SFTP, and local file systems, and the app runs on Windows, Linux, macOS, Xbox, Surface Hub and HoloLens. Seven storage backends behind one view model layer is a much better demonstration of a reactive architecture than three would be, because each backend forces the abstraction to be real rather than decorative.

The code lives under src/, with the build automation in a .nuke/ directory and the build entry points as build.sh, build.ps1 and build.cmd at the root. The licence is MIT, the primary language is C#, and the last push was on 2026-10-16, so the sample is being kept in step with the framework it demonstrates.

One view model layer, seven storage backends

The mechanism that makes this work is the ReactiveUI stack, and the technology list explains what each piece is for.

ReactiveUI is the MVVM framework itself. ReactiveUI.Validation is the reactive validation library, which is how a view model exposes field level errors as observable state rather than through explicit validation calls. ReactiveUI.Events turns regular events into observables, so a component that raises an event can be consumed like any other stream. DynamicData provides reactive collections, which is the part that does the real work when a directory listing changes.

The pattern this enables is worth spelling out, because it is the thing the sample exists to teach. A file browser has a natural shape of a stream of changes: a directory is loaded, its contents arrive, the user navigates into a subdirectory, the listing is replaced, the user goes back, the previous listing is restored. With plain collections and manual event handlers, that shape turns into a tangle of state synchronisation bugs. With DynamicData and observable view models, the listing becomes a stream that the view binds to, and navigation becomes a change in the source of that stream rather than a sequence of imperative updates.

Akavache is the persistent key value store, and it is there for caching, which matters more than it first appears. Without a cache, every navigation is a network round trip to a cloud provider, and an application that feels slow teaches nothing about reactive design.

The provider specific libraries are all in the list, and they show the shape of the abstraction: Octokit for GitHub, FluentFTP for FTP, SSH.NET for SFTP, VkNet for the VKontakte SDK, and the Google API .NET client for Google Drive. Each is wrapped behind the same interface, and that is the architectural point of the whole exercise.

The project also uses Costura.Fody, which embeds the references as resources, so the produced application carries its dependencies inside the binary rather than expecting them to be installed separately.

Four solutions, and four different toolchains to build them

The repository ships four separate solutions rather than one multi-targeted project, and that decision explains most of the build complexity.

The Avalonia solution is the modern one. To compile the .NET Standard libraries, run the tests and run the Avalonia application on Windows, Linux or macOS, you need the latest .NET Core SDK installed, and you open the Camelotia.Avalonia.sln file. The build and test are driven by Nuke Build, and the commands are the same on Linux and macOS:

git clone https://github.com/worldbeater/Camelotia
cd ./Camelotia && bash ./build.sh --interactive

The interactive flag launches the Avalonia app after the build.

On Windows the equivalent is:

git clone https://github.com/worldbeater/Camelotia
cd ./Camelotia && powershell -ExecutionPolicy Unrestricted ./build.ps1 --interactive

and the comment explains the extra options. The --full option compiles the Android, UWP and WPF apps as well, and the --configuration Release option generates app packages.

The UWP solution is the most constrained. It targets Windows 10 based devices such as PCs, Xbox One and HoloLens, it can be compiled only on the latest Windows 10, it requires Microsoft Visual Studio with the Universal Application Development section checked in the installer, and you launch Camelotia.Uwp.sln.

The WPF solution requires the Desktop Development section in Visual Studio, and the documentation says to open Camelotia.Wpf.sln in Visual Studio 2019. The Xamarin.Forms solution needs Android SDK v8.1, the Mobile Development section in the installer, and Camelotia.Xamarin.sln.

So the cost of this sample is that each of those stacks has its own prerequisites, and some of them are historical. UWP is a Windows only line, WPF on Visual Studio 2019 is a specific IDE version, and Xamarin.Forms has been superseded in the .NET line. The Avalonia path is the one that will build on a current machine, and the other three are there to prove the portability claim rather than to be your starting point.

The WPF port exists so you can copy its source files

One line in the documentation explains the WPF version better than any amount of architectural commentary.

The app was ported to WPF to make the cloud file manager controls reusable across most popular .NET implementations, so one could easily embed parts of Camelotia into their own applications by simply copying and pasting the source files. The WPF build is also compatible with Windows versions lower than 10, such as Windows 7 or 8.

Copy and paste is an unusual distribution strategy for a component library, and it says something about the era the project was written in. Before there was a mainstream .NET cross platform UI framework, the way to share a control was to hand someone the files. The Avalonia port is the answer to that, and it is the one that will age well.

The compatibility with Windows 7 and 8 is a second signal about the vintage of the WPF target, and it is a reminder that a sample application ages in ways a maintained library tries not to.

For a reader, the useful thing to take from the WPF solution is the shape of the separation: the file manager controls, the view models, and the provider abstraction are in different assemblies, so the WPF-specific parts are thin. That is the property that makes copy and paste viable, and it is the property worth copying whether you target WPF, Avalonia or something else.

The test and tooling stack is as deliberate as the UI stack

The technology list spends as much attention on how the project is verified as on how it is drawn, and that is the part a sample application should model.

XUnit is the unit testing tool for .NET. Coverlet is the code coverage analyser. NSubstitute is the mocking library and FluentAssertions is the assertions library, so a view model can be tested without a UI and without hand written stubs. The repository carries a codecov badge, which means coverage is published rather than merely computed.

The combination matters more than the individual tools. A reactive view model has a lot of moving parts, and the usual failure mode is that the tests end up asserting on the timing of the streams rather than on the state, which makes them flaky and eventually useless. A sample that ships with mocking and assertion libraries and a coverage badge is showing the method, not just the result.

The IDE support is also part of the picture. JetBrains Rider and Microsoft Visual Studio are both listed, and there is an AvaloniaRider plugin for visual designer support, which is the kind of detail that only matters if you actually intend to work in Rider.

The UI layers are equally varied on purpose. AvaloniaUI is the cross-platform XAML based GUI framework, Citrus.Avalonia is a bright and modern theme for it, and on the Microsoft stacks the sample uses Material Design in XAML Toolkit and MahApps Metro for controls and styled windows. The presence of two different control toolkits on the Windows side, plus a designer plugin, is what makes the sample look like an application rather than a diagram.

Sponsorship, CI and a repository that is still being worked on

The project is a community sample with commercial support behind it, and the sponsorship section says so.

JetBrains gives the ReactiveUI maintainers licences for their tools through its open source support programme, Anthropic supports them with Claude through Claude for Open Source, and OpenAI is named in the same list. That is a sponsorship arrangement, and it is a useful signal about who benefits from the framework's maintenance.

The repository itself is in good order for a sample. There is a build workflow, the ci-build.yml file, with a status badge, a codecov badge for coverage, an .editorconfig for formatting, a CODE_OF_CONDUCT.md, a SECURITY.md, and a CODE_OF_CONDUCT file at the root alongside the LICENSE file. The .nuke/ directory holds the Nuke build definition, and there are three build entry points, build.sh, build.ps1 and build.cmd, so the same build definition can be driven on Unix shells and on Windows.

The repository is not archived, and the last push was on 2026-10-16, which is recent. There are no GitHub releases, which is normal for a sample that is consumed as source rather than as a package.

One small thing to be aware of if you follow the build instructions literally. The clone commands in the documentation point at the worldbeater fork of the project rather than at the reactiveui repository itself, which reflects the history of the code. If you want the current state, clone the repository you are reading this in, not the one in the snippet.

The MIT licence makes the reuse question simple in one respect and complicated in another. You may copy the code into your own product, including commercially, and you must keep the notice. What you do not get is a promise that the sample will keep compiling against tomorrow's .NET, so if you copy the WPF or Xamarin solutions you are also inheriting their toolchain.

Editorial conclusion

Use Camelotia if you are evaluating ReactiveUI or need a working reference for a reactive MVVM file manager across desktop and mobile .NET stacks. Do not adopt it as a production file manager, because it is explicitly a sample, it targets storage providers that require per service credentials, and its Windows and Xamarin builds depend on toolchains that are no longer the default for .NET development. Before using it, build the Avalonia solution with build.sh --interactive, confirm the storage provider you care about authenticates in your environment, and read the view model and test projects to see how much of the pattern is worth copying.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. reactiveui/Camelotia on GitHub
5. README