AvaloniaRider: an XAML previewer and scaffolding templates for Rider
JetBrains Rider plugin for Avalonia development
At a glance
- What is it?
- AvaloniaRider is a JetBrains Rider plugin that adds an interactive XAML preview to the IDE, file and live templates for Avalonia controls and attached properties, and a set of theme injection settings. It can render previews either through a bitmap-based AvaloniaRemote process or through a browser, and it can run the previewer under a debugger.
- Who is it for?
- AvaloniaRider suits a team working on Avalonia in Rider who wants a live XAML preview and the standard Avalonia scaffolding without writing the markup by hand, and the theme injection settings are the part that saves the most time when matching a design system. It does not suit you if your IDE is not Rider, since the plugin is built against the IntelliJ platform and the marketplace listing is Rider specific.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The previewer needs a runnable project, which is the first thing to understand
AvaloniaRider is a JetBrains Rider plugin for Avalonia development, and its headline feature is an XAML preview inside the IDE.
The usage instructions are short. Make sure your Avalonia project is built, open an XAML file, and you will see an XAML preview in Rider. The preview is interactive with the mouse, and you can zoom with Ctrl+Scroll Wheel.
The important constraint is stated in the settings section rather than up front, and it is the thing that trips up new users. The previewer needs some runnable project to work because it observes the UI of your components from the perspective of the project. In other words, this is not a static renderer that parses your XAML and draws it. It runs your component in a real application process and looks at the result.
That design explains the rest of the plugin. The previewer has to run code, so it needs a project, and a project means a build, a working directory, an output directory and a process that can be started and stopped. It also means the preview reflects your component's behaviour, not just its markup, which is considerably more useful when the bug you are chasing is in a binding rather than in a layout.
The consequence for a team is that the previewer is a development tool with a real dependency on the build, and the first run is slower than a static render would be. The plugin compensates with settings that let you control how the previewer process is launched and where it runs.
Two previewer backends, and how to debug the previewer itself
The previewer method setting offers either the bitmap-based AvaloniaRemote, which is the default, or the browser-based Html.
Those two are different renderers with different consequences. AvaloniaRemote renders the UI as pixels, which means what you see matches what the application will show, and it is the option that gives an accurate preview of a custom-drawn control. The Html option renders in a browser, which is faster to start and easier to inspect, but it is a different rendering path, so it will not be pixel identical to the real thing.
The plugin also lets you attach a debugger to the previewer process for the current file, but the button is hidden by default. To enable it, you go to the Avalonia settings page in Rider and enable the Developer mode checkbox.
That setting is described twice, once in the solution-wide settings and once among the IDE-wide settings, and the IDE-wide version explains what it is for: if enabled, the plugin will show the Debug button in the previewer, allowing you to run the previewer process under a debugger, in cases when you want to debug preview-specific issues, such as blocks under Design.IsDesignTime.
That last example is the reason this feature exists. Design.IsDesignTime is the standard Avalonia mechanism for code that should only run in a designer, and if that block misbehaves you need a debugger pointed at the previewer, not at your app. The plugin making the previewer process debuggable is a small feature with a narrow but real purpose.
File templates and live templates for the Avalonia vocabulary
The scaffolding side of the plugin covers two mechanisms, and they do different jobs.
File templates are what you get from the New menu. You right-click a directory or an Avalonia-enabled project and choose among the available templates. For XAML there are five: Avalonia User Control, Avalonia Templated Control, Avalonia Window, Avalonia Resource Dictionary and Avalonia Styles. For C# there are two: Avalonia Converter and Avalonia Multi Converter.
The distinction between the XAML templates is worth noting because the differences matter when you scaffold. A User Control is a composable piece, a Templated Control is a control with a template that another XAML file overrides, a Window is a top level, a Resource Dictionary holds shared resources, and Styles holds style definitions.
Live templates are the expansion you get while typing in an editor, and this plugin provides four: attachedAvaloniaProperty, avaloniaRoutedEvent, directProperty and styledProperty.
These four map onto the distinction that trips up people arriving from WPF. A styled property participates in the styling system and can be set by a style, a direct property cannot, an attached property is a property that belongs to one type but is set on another, and a routed event is an event that travels up the visual tree rather than only raising on the element itself. Writing those declarations by hand is tedious and easy to get subtly wrong, and having an expansion that produces the correct declaration is exactly the kind of small quality-of-life difference that makes an IDE plugin worth installing.
The templates are also Avalonia-specific rather than generic, so a WPF user will not find the same set of expansions here, which is correct, since the property and event vocabularies differ between the two frameworks.
Theme injection, the working directory, and the shadow copy of your build output
The solution-wide settings live under Settings, then Languages and Frameworks, then Avalonia, and several of them address real friction.
Theme injection is the most interesting. There are settings for applicable elements, which by default are Window and UserControl, and for the default theme, plus separate dark theme and light theme markup for injection. These XML snippets will be injected directly after the first tag in the XAML markup, and by default they control the RequestedThemeVariant style property.
That is a substantial timesaver in a real application, because the mechanism for declaring a theme in Avalonia normally means editing a resource dictionary and wiring it up in every place that needs it. Injecting the markup directly after the first tag of the applicable elements does it once.
The working directory setting has two options. Defined by MSBuild uses the $(RunWorkingDirectory) MSBuild property, or generally what Rider considers the default for the selected project. Solution directory uses the directory containing the solution file. If you want to override it, you may modify your project file as follows:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<!-- … -->
<!-- Add this new line! -->
<RunWorkingDirectory>H:\Your\Custom\Work\Directory</RunWorkingDirectory>
</PropertyGroup>
<!-- … -->
</Project>The shadow copy option is the other one worth understanding. When starting the previewer, it will copy all the files from the bin directory to a separate place and use them to work with the previewer. The stated reason is that this will prevent the previewer from locking the assemblies from the original place.
That is a classic .NET problem. A running process holds its assemblies open, and if the previewer runs from your normal build output, a subsequent build fails to overwrite the files in bin. Copying to a separate location sidesteps it, at the cost of a copy per previewer start.
The FPS limit setting limits the FPS, and thus the CPU usage, of the AvaloniaRemote previewer, which by default tries to provide smooth animation support, which might be unwanted at times.
Distribution through the marketplace, and the development release channel
The plugin ships through the standard JetBrains marketplace. For a stable release you either search for Avalonia on the Plugins settings page or visit the Plugin Marketplace, where the plugin is listed as AvaloniaRider with the version badge in the README header pointing at the listing.
There is also a development release channel, and it is worth knowing how it works because it changes how you test a plugin that moves quickly. A development release is automatically published for every push into a development branch. To install one you first add the custom plugin repository into your IDE, and the address is:
The custom plugin repository address is https://plugins.jetbrains.com/plugins/dev/14839
Then you install the plugin as usual via the IDE plugin settings screen. The instructions link to the JetBrains documentation on how to add custom plugin repositories, which is the part people usually have to look up.
The release cadence is regular. Version 1.11.0 was published on 2026-03-07, 1.12.0 on 2026-06-06 and 1.13.0 on 2026-08-02, with the last push to the repository on 2026-10-20. Minor versions roughly every three months is a sensible rhythm for an IDE plugin, and the fact that a development build is available for every push means you can try an unreleased fix without waiting for the next tag.
The repository is Kotlin, built with Gradle, with a gradle.properties, settings.gradle.kts, build.gradle.kts, a gradlew wrapper, a .run/ directory for run configurations and an .idea/ directory. The protocol/ directory at the root is the one structural clue about how the plugin works, since a previewer that runs in a separate process needs a way to talk to the IDE. There is a testData/ directory for the tests, a scripts/ directory, an intellij-updater.json for the marketplace versioning, a renovate.json for dependency updates, and the documentation set in the root, with CHANGELOG.md, CONTRIBUTING.md, LICENSE.md and MAINTAINERSHIP.md, the last of which is unusual and suggests the project takes the question of who maintains it seriously.
Editorial conclusion
AvaloniaRider suits a team working on Avalonia in Rider who wants a live XAML preview and the standard Avalonia scaffolding without writing the markup by hand, and the theme injection settings are the part that saves the most time when matching a design system. It does not suit you if your IDE is not Rider, since the plugin is built against the IntelliJ platform and the marketplace listing is Rider specific. Before you rely on it, check which previewer method you want, because AvaloniaRemote is bitmap based and the Html option is browser based and therefore not pixel identical, and remember the previewer needs a runnable project bound to it, which is the setting people usually miss first.
Frequently asked questions
How do I use the AvaloniaRider XAML previewer?
Make sure your Avalonia project is built, open an XAML file, and the preview appears in Rider. You can interact with it with the mouse and zoom with Ctrl+Scroll Wheel, but the previewer needs a runnable project bound to it because it observes the UI of your components from the perspective of that project.
What is the difference between the AvaloniaRemote and Html previewer methods?
AvaloniaRemote is the bitmap-based default, so what you see matches the real application rendering. Html is the browser-based option, which is quicker to start and easier to inspect but is not pixel identical to the real thing.
How do I debug the AvaloniaRider previewer process?
Enable the Developer mode checkbox on the Avalonia settings page in Rider. The Debug button in the previewer is hidden by default, and with developer mode on you can run the previewer under a debugger, which is how you investigate code that only runs under Design.IsDesignTime.
How do I install a development build of AvaloniaRider?
Add the custom plugin repository https://plugins.jetbrains.com/plugins/dev/14839 to your IDE using the JetBrains documentation on custom plugin repositories, then install the plugin as usual from the IDE plugin settings screen. Development releases are published automatically for every push into a development branch.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/fornever-avaloniarider)Was this useful?