MudBlazor.Templates ships dotnet new templates with the interactivity mode already chosen

What the package actually is: two dotnet new templates

MudBlazor.Templates is a package of ready-to-use templates for MudBlazor in different styles and layouts, with all the basic setup already done for you.

In practice it installs two template commands, and the README names them explicitly. The first, mudblazor, is a MudBlazor Web App with Blazor Web App interactivity modes. The second, mudblazorwasm, is a MudBlazor WebAssembly Standalone App.

That split is the whole design decision, and it maps onto the two ways Blazor applications run today. The Web App template covers the server-rendered model with optional interactivity, including the Auto mode where a component becomes interactive only when it needs to be. The standalone template covers the client-side WebAssembly model, which ships the runtime to the browser.

The newest addition is the .NET 10 Web Apps template, which the README announces as based on the Microsoft Web App template but modified to include MudBlazor components. That lineage matters for one practical reason. Microsoft own templates are regenerated with each .NET release, and a template that tracks the official one inherits those changes, including the newer hosting model that replaced the older Blazor Server and Blazor WebAssembly split.

The repository is small and structured around the packaging. The top level has src/ for the template sources, content/ holding the MudBlazor logo assets, an InstallAndBuildAllTemplates.ps1 script for building from source, and the standard CONTRIBUTING.md, CODE_OF_CONDUCT.md, LICENSE and README.md. The default branch is dev, which tells you where the work happens before a release.

Installing, updating and pinning the template package

Installation is one command, and the prerequisites are the .NET 10 SDK plus Visual Studio 2026, JetBrains Rider or Visual Studio Code.

dotnet new install MudBlazor.Templates

Updating an existing installation is separate, and the README is careful to note that dotnet new update checks installed template packages and installs available updates, and that it updates all installed template packages rather than just MudBlazor.Templates.

dotnet new update

There is a preview mode that changes nothing, which is the safe way to see what would happen.

dotnet new update --check-only

And to see what is installed or available, you list the two template names.

dotnet new list mudblazor
dotnet new list mudblazorwasm

Reinstalling by hand is the route for pinning a specific version, and the package identifier for that uses a double colon.

dotnet new uninstall MudBlazor.Templates
dotnet new install MudBlazor.Templates

dotnet new install MudBlazor.Templates::<version>

That last form is worth remembering. Templates age with the SDK they target, so a template pinned to an old MudBlazor and an old .NET baseline will not build against a current SDK. Pinning is fine for reproducing an old application, but it is a trap for a new one.

The templates also appear in Visual Studio's Create a new project list. The README says the CLI examples are the best reference for advanced combinations and flags, since the common options map to the Visual Studio project creation UI.

The interactivity switch decides what kind of app you are building

The option table in the README is the most useful part of the document, because one of the switches changes the architecture of the application rather than its appearance.

The interactivity option, -int or --interactivity, accepts Auto, None, Server or WebAssembly, and the default is Server. Use None for static server-side rendering only.

That default is worth examining. A plain invocation produces a server-interactive app, so the template is not the conservative choice; it is the interactive one.

dotnet new mudblazor -o MyMudApp

The static variant omits interactivity entirely.

dotnet new mudblazor -o MyMudApp -int None

The Auto mode gives per-page interactive components.

dotnet new mudblazor -o MyMudApp -int Auto

And the global variant turns interactive rendering on for the whole application, which the README notes is only enabled when interactivity is not None.

dotnet new mudblazor -o MyMudApp -int Auto -ai

That -ai flag is the one to think about before using. Global interactivity means every component renders over a live circuit rather than as static markup, which changes how the page behaves on load and how much server work each interaction causes.

The remaining options are more conventional. -au or --auth takes None or Individual and defaults to None. -uld or --use-local-db switches to LocalDB instead of SQLite and only applies with -au Individual. -e or --empty omits the sample pages and demo styling. --no-https disables HTTPS for local development and is ignored when -au Individual is used. The rest are plumbing: --exclude-launch-settings drops Properties/launchSettings.json from the generated output, --no-restore skips the automatic dotnet restore after project creation, --use-program-main generates an explicit Program class and Main method instead of top-level statements, and --localhost-tld uses the .dev.localhost TLD in the local application URL.

For the full list, including advanced template options, the README points at dotnet new mudblazor --help.

Authentication and database choices are template switches too

Authentication is configured at generation time, which is the reason the -au option exists at all rather than being added afterwards.

Individual authentication is the default option value you would reach for.

dotnet new mudblazor -o MyMudApp -int Auto -au Individual

And the same with global interactivity added on top.

dotnet new mudblazor -o MyMudApp -int Auto -au Individual -ai

The database choice rides along with it. With Individual authentication you can opt for LocalDB instead of SQLite, which is the -uld flag.

dotnet new mudblazor -o MyMudApp -au Individual -uld

LocalDB is the Microsoft SQL Server Express local database, so the -uld switch exists for developers on Windows whose tooling expects it, while the default keeps the template on SQLite for cross-platform work.

For the standalone WebAssembly template the auth options are wider, because a client-side application has different identity providers available to it.

dotnet new mudblazorwasm -o MyMudWasmApp --auth Individual

dotnet new mudblazorwasm -o MyMudWasmApp --auth IndividualB2C

dotnet new mudblazorwasm -o MyMudWasmApp --auth SingleOrg

Individual is the plain identity store, IndividualB2C is Azure AD B2C, and SingleOrg is single-tenant organisational auth.

The README notes a detail about the Individual variant for the standalone template: it exercises the MissingAuthority guidance by default until provider values are configured. That is the template pointing at a known gap in the setup rather than leaving you to discover it, and it is a good example of what a well-built template does.

There is also a progressive web app variant and an empty variant.

dotnet new mudblazorwasm -o MyMudWasmApp --pwa

dotnet new mudblazorwasm -o MyMudWasmApp --empty

Sample variants and the option to strip everything back

The templates ship with demo content, and there is a documented way to get an option that generates a variant with the Call Web API sample navigation and page, which the README says exercises B2C with non-default API settings.

dotnet new mudblazorwasm -o MyMudWasmApp --auth IndividualB2C --called-api-url https://example.com/api --called-api-scopes api.read

Two things are worth noticing. The called-api-url and called-api-scopes options take values, so they are part of the template's configuration surface and not hardcoded strings. And the sample is the way to see how the template wires a client-side app to a protected API, which is a common requirement and an annoying one to configure by hand.

If you want none of the demo content, the empty switch is there for both templates.

dotnet new mudblazor -o MyMudApp -e

dotnet new mudblazorwasm -o MyMudWasmApp --empty

That flag omits the sample pages and the demo styling, which is what you want for a real application. The demo styling in particular is the kind of thing that quietly ends up in production if nobody strips it, so generating with the empty option and adding your own theme is the cleaner starting point for most projects.

Two more options complete the picture. --use-program-main generates an explicit Program class and Main method rather than top-level statements, which matters if you are moving code between projects with different language versions. And a custom project name with a custom output folder is a single command.

dotnet new mudblazor -n Acme.Portal -o src/Acme.Portal -int WebAssembly

Note that the -int WebAssembly value here selects the WebAssembly interactivity mode inside the Web App template, which is a different thing from using the standalone mudblazorwasm template.

Releases and the .NET 10 gap in the tag history

The maintenance picture is worth reading carefully, because the README and the release list tell different stories.

The listed releases are v0.6.1 from 2022-02-10, v0.6.0 from 2021-12-19, and v0.1.6 from 2021-10-06. So the last tagged release in the repository is more than four years old.

The README, meanwhile, announces a .NET 10 Web App template with a full options table covering interactivity modes, authentication and database selection. The last push was on 2026-10-16 and the repository is not archived, and the default branch is dev.

The reasonable reading is that development continues on dev and that releases are published to NuGet, since the README points at a NuGet package page for MudBlazor.Templates with a version badge and a downloads badge. The GitHub tags are not where you would look for the current version.

That has a practical consequence. If you want to know exactly what a given version of the template produces, you install that version and read the help output, because the README reflects the current state of the dev branch rather than a pinned release. The version pinning syntax, dotnet new install MudBlazor.Templates::<version>, is the tool for pinning.

The repository also carries an InstallAndBuildAllTemplates.ps1 script at the top level, which is the route for testing template source changes that have not been published. The README instructs you to clone the source and execute that script, and notes that you may get an error about the script if something is missing, with the guidance truncated in the README itself.

On licensing, the repository is MIT with a LICENSE file at the root. The badge in the README points at an earlier repository name, Garderoben/MudBlazor.Templates, which reflects the project's history as it moved into the MudBlazor organisation.

Where the templates are the wrong tool

Three cases rule it out, and they are all about the scaffolding being the product.

The first is an existing application. If you already have a Blazor or MudBlazor project, these templates do nothing for you. They generate a new project; they are not components you add to an existing one. Adding MudBlazor to an application you have already built is a matter of following the MudBlazor setup instructions, and generating a template to get there would mean throwing away work.

The second is a team that wants a bare starting point. The empty option strips the demo pages and demo styling, but the template still carries a layout, a navigation structure and MudBlazor provider setup. If your application has its own shell, that shell is now something to delete rather than something you never wrote.

The third is a runtime version mismatch. The template targets .NET 10 and expects the .NET 10 SDK with a current IDE. If your organisation is on an earlier LTS, or if you are supporting a range of SDK versions across a team, the template and your toolchain will disagree. That is why the pinning syntax exists, and why a pinned old template is a maintenance liability rather than a solution.

There is one more consideration that is not a limitation but a habit worth forming. The templates generate an app with interactivity already decided, defaulting to Server. If you have not thought about the render mode, the default will pick for you. A static server-rendered app generated with -int None is a different application from a server-interactive one, and changing that later means revisiting every component that assumed it had a live circuit.

The alternative approach is the manual route: create a project with the Microsoft templates, add the MudBlazor package, and follow the MudBlazor setup documentation to add the provider, the fonts and the styles. That is more work, and it is the only option when you need to diverge from what the template assumes.

Editorial conclusion

Adopt MudBlazor.Templates if you are starting a MudBlazor application on .NET 10 and want the render mode, authentication wiring and layout decided for you instead of assembled by hand from the MudBlazor setup guide. Do not adopt it if you already have a Blazor application, because the value is entirely in the scaffolding, and check the package version you install, since the release tags in the repository stop at 0.6.1 from 2022 while the README describes a .NET 10 template. Before you generate, read the options table in the README and pick your interactivity mode deliberately, since -int None produces a static server-rendered app that will need revisiting the moment you want interactivity.

Frequently asked questions

Official sources

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