Avalonia.Templates gives dotnet new eight starting points for a cross platform UI

What a template pack for dotnet new actually is

Avalonia.Templates is not a UI framework and not a code generator library. It is a package of project templates that the dotnet CLI can serve, which is why the whole thing is installed with a single command and then appears in the template list like any built-in template.

dotnet new install Avalonia.Templates

After that the templates are visible in the CLI's own listing, and the README shows what the user sees.

Template Name                        Short Name                 Language  Tags
-----------------------------------  -------------------------  --------  -----------------------------------------
Avalonia .NET App                    avalonia.app               [C#],F#   Desktop/Xaml/Avalonia/Windows/Linux/macOS
Avalonia .NET MVVM App               avalonia.mvvm              [C#],F#   Desktop/Xaml/Avalonia/Windows/Linux/macOS
Avalonia Cross Platform Application  avalonia.xplat             [C#],F#   Desktop/Xaml/Avalonia/Web/Mobile

Eight templates ship, and the short names are the handle you actually type. The desktop set covers an app, an MVVM app, a window, a user control, a styles list and a resource dictionary, all tagged for Windows, Linux and macOS, while the cross platform application is tagged for Web and Mobile as well. The resource and styles templates have no language, which makes sense since they produce markup rather than code. The audience is a .NET developer who has chosen Avalonia for a UI and wants the first commit to look like something the framework's maintainers would write.

C# by default, F# with a flag

The language handling is the first thing the README flags, and it is a genuine sharp edge rather than a detail. By default the dotnet CLI would create a C# template, and if you want an F# template you have to add the language argument to the end of the command. So a developer who types the short name and expects F# gets a C# project, and the fix is a flag that is not in the short name. The templates themselves are listed with both languages in the Language column, which is accurate but does not tell you which one you get by default. Two other things in the listing are worth a second look. The desktop templates are tagged with the three desktop platforms, and the cross platform one with Web and Mobile, which tells you the difference in scope between avalonia.app and avalonia.xplat before you generate anything. And the templated control template is a separate entry, which matters for a project that defines its own custom controls, since a control with its own template needs a different starting shape than a window.

The app template and the parameters it exposes

The barebones application is generated with a name and an output directory, and the output directory is a separate switch rather than a convention, so the project lands in its own subdirectory.

dotnet new avalonia.app -o MyApp

Three parameters are documented. The framework parameter, -f or --framework, chooses the target framework with the options net10.0, net9.0 and net8.0, and net10.0 is the default. The Avalonia version parameter, -av or --avalonia-version, sets the target version of the Avalonia NuGet packages, and the default is 12.1.4. The no-restore flag skips the automatic restore of the project on create, which matters when you are generating inside a build script or a CI pipeline and you do not want the template to reach out to the network before you have pinned your own package sources. The default Avalonia version of 12.1.4 is worth noting against the release list, where the template package itself is on 12.1.2, so the templates can generate projects against a slightly newer Avalonia than the template version would suggest. The repository listing shows the mechanics behind this. There is a templates/ directory, a tests/ directory, an Avalonia.Templates.csproj for the package itself, a nuget.config, and install-dev-templates.ps1, which is the script that installs a locally built template set so a contributor can test their changes without publishing.

MVVM is the recommended shape, and the toolkit choice is yours

The README states that MVVM is the recommended pattern for creating Avalonia applications, and the MVVM template uses ReactiveUI to ease building applications with complex interactions. The naming deserves a second look, because the template does not hard code ReactiveUI any more. The -m or --mvvm parameter selects the MVVM toolkit, with the options ReactiveUI and CommunityToolkit, and the default is CommunityToolkit. So the sentence in the README about ReactiveUI describes the heritage of the template, while the parameter lets you pick the community toolkit instead, and that default is the one you get unless you pass the flag. The generated code therefore depends on a choice you may not have made deliberately, which is the kind of thing to check in the first commit. The other MVVM specific parameter is -rvl or --remove-view-locator, which removes the default ViewLocator, and the README gives the reason: the default ViewLocator is not trimming friendly, so the flag is useful for code trimming scenarios. It defaults to false, so the trimming-unfriendly ViewLocator is in your project unless you ask for it to be gone. The cross platform template carries the same -m and -rvl parameters plus -cpm, which turns on Central Package Management, and the note says that if it is disabled, a Directory.Build.props will be created with the shared Avalonia version.

The cross platform template has a version floor and a wider surface

The cross platform application template is the one with a constraint attached to it, and the constraint is a version. The README says this template creates an application that works on Desktop, Browser and Mobile with iOS and Android, and that it is only available with 11.0 preview versions and newer. So if you are targeting an Avalonia release before 11.0, this template simply is not an option, and the choice narrows to the desktop app template. The parameter set also differs, and the difference is worth reading closely. The cross platform template has no framework parameter, so you do not choose net10.0 or net8.0 for it, and it does not have a no-restore flag. It has the Avalonia version parameter, the MVVM toolkit parameter, the remove-view-locator parameter and the CPM parameter. The CPM parameter is the interesting one, because it changes how your project manages package versions, not just what is in it. Use Central Package Management is the option, the default is true, and when it is disabled a Directory.Build.props is created holding the shared Avalonia version. That is a structural choice about the whole repository layout, made at scaffolding time, and it is the sort of decision that is much harder to reverse later than the ViewLocator.

Windows, controls, styles and resources

The remaining four templates are for the pieces you add to a project once the application shell exists, and the naming convention is consistent. A window called MyNewWindow in the namespace MyApp is generated with the -na and -n switches, and a user control called MyNewView in the same namespace uses the same pair of switches.

dotnet new avalonia.window -na MyApp -n MyNewWindow

dotnet new avalonia.usercontrol -na MyApp -n MyNewView

The styles list and the resource dictionary take only a name. The styles template produces a Styles list called MyStyles, and the resource dictionary produces a ResourceDictionary called MyResources. The resource dictionary is the one to understand, because in Avalonia the resource dictionary is where shared resources live, whether they are colours, brushes, control themes or converters, and a project that grows past one screen ends up with several of them. Generating them from a template means the file lands in the right place with the right XAML root element rather than being hand written each time. The templates are published to NuGet as Avalonia.Templates, with the download badge pointing at the package page, and the README links a blog post explaining how to create your own templates for dotnet new for anyone who wants to go further. The repository also carries an AGENTS.md file alongside DEVELOPMENT.md, which suggests the project is set up for assisted contribution workflows as well as human ones.

Editorial conclusion

Avalonia.Templates suits a .NET developer starting a cross platform desktop application on Avalonia who wants the scaffolding to match the framework's own conventions rather than a hand rolled project, and who will read the generated files before building on them. It is the wrong tool if you want a bare project with no Avalonia at all, since every template here is Avalonia specific, and it is the wrong tool if you already have a house style for project layout, because the templates bring a ViewLocator, a MVVM toolkit choice and a central package management setup that you would then have to unpick. Before you generate anything, decide whether you want ReactiveUI or the CommunityToolkit, because that choice is baked into the MVVM and cross platform templates, and read DEVELOPMENT.md, which the README points to for how to build, test and extend the template set.

Frequently asked questions

Official sources

1. AvaloniaUI/Avalonia.Templates on GitHub
2. Issues
3. License: MIT
4. README
5. Releases