/create-blazor-project

license: MIT
name: create-blazor-project
description: >
  Create a new ASP.NET Core web application or web site using Blazor.
  USE FOR: creating a new Blazor web app, scaffolding a new web project,
  starting a new web site, choosing render modes (Static SSR, Interactive Server,
  Interactive WebAssembly, Auto), running dotnet new blazor with the right options,
  setting up initial project structure.
  DO NOT USE FOR: adding features to existing projects, changing how an existing
  app renders, or component authoring (use author-component).

Create a Blazor Web App

Before You Start — Gather Requirements

If the user's request doesn't make the following clear, ask before scaffolding:

1. **What does the app do?** List the main screens/features (e.g., "product catalog with search and shopping cart"). 2. **What kind of interactivity is needed?** Displaying data and forms? Real-time updates? Offline support? Rich drag-and-drop UI? 3. **Deployment environment?** Internet-facing? Intranet? Mobile users on slow connections? 4. **Authentication needed?** Anonymous? Individual accounts? Organizational (Azure AD)?

Pick the Right Interactivity Level

Blazor render modes are a progression scale. Start at the simplest level that satisfies the requirements and only move up when there's a concrete reason.

Static SSR ──→ SSR + Enhanced Nav ──→ Interactive Server ──→ Interactive WebAssembly
 simplest                                                           most complex

Decision Rules

| If the app needs... | Use | Why | |---|---|---| | Display data, simple forms, links between pages | **Static SSR** (`-int None`) | No JS runtime, no circuit, no WebAssembly download. Forms work via HTML POST. Enhanced navigation makes it feel snappy. | | Everything above + a few components with client-side behavior (live search, real-time updates, complex form wizards) | **Interactive Server, per-page** (`-int Server`) | Only the components that need interactivity opt in with `@rendermode`. The rest stays static. Server-side execution, full .NET access, no API layer needed. | | Most pages need rich interactivity (dashboards, drag-and-drop, chat) | **Interactive Server, global** (`-int Server -ai`) | Every component is interactive by default. Consistent UX, simpler mental model. Trade-off: every user holds a SignalR circuit on the server. | | Network latency is a problem, users are on mobile/poor connections, or the app must work offline | **Interactive WebAssembly** (`-int WebAssembly`) | Code runs in the browser. Eliminates round-trip latency but requires a `.Client` project, API layer for data access, and downloads the .NET runtime to the browser on first visit. For offline support, enable PWA: add a service worker and manifest after scaffolding (not included in the template by default). | | Fast initial load (Server) + low latency after (WebAssembly) | **Interactive Auto** (`-int Auto`) | First visit uses Server; subsequent visits use cached WebAssembly runtime. Most complex setup — see Auto constraints below. Only choose when both Server and WebAssembly constraints apply. |

**Default recommendation:** Start with `-int Server` (per-page). It covers the vast majority of apps. Upgrade to global or WebAssembly only when a specific requirement demands it.

Auto Mode Constraints

Auto mode means your component code runs on the server first, then in the browser on subsequent visits. This creates real constraints:

• **All interactive components must live in the `.Client` project** — same as WebAssembly.
• **No direct server access** from interactive components — no EF `DbContext`, no file system, no server-only services. All data access must go through HTTP APIs.
• **Both `Program.cs` files must register matching services** — the server and client DI containers must both provide implementations for any service an interactive component injects.
• **Code must not assume its execution environment** — no `HttpContext` access, no browser-only APIs without `RendererInfo` guards.
• **Test in both modes** — a component that works on Server during development may break on WebAssembly in production (second visit). Test both paths.

Don'ts

• Don't pick WebAssembly "because it's cool" — it adds a `.Client` project, forces API-mediated data access, and downloads ~10MB to the browser on first visit.
• Don't pick Auto unless you can articulate why Server alone and WebAssembly alone are both insufficient.
• Don't pick global interactivity for apps where most pages are read-only content — per-page keeps the static pages fast and reduces server memory.

Scaffold the Project

Static SSR Only (display data + simple forms)

dotnet new blazor -o {AppName} -int None

No interactive runtime. Enhanced navigation enabled by default via `blazor.web.js`.

Interactive Server, Per-Page (recommended default)

dotnet new blazor -o {AppName} -int Server

Pages are static by default. Add `@rendermode InteractiveServer` to components that need interactivity.

Interactive Server, Global

dotnet new blazor -o {AppName} -int Server -ai

All pages interactive via `<Routes @rendermode="InteractiveServer" />` in `App.razor`.

Interactive WebAssembly, Per-Page

dotnet new blazor -o {AppName} -int WebAssembly

Creates `{AppName}` (server) and `{AppName}.Client` (WebAssembly) projects. Interactive components must live in `.Client`.

Interactive WebAssembly, Global

dotnet new blazor -o {AppName} -int WebAssembly -ai

Interactive Auto, Per-Page

dotnet new blazor -o {AppName} -int Auto

Interactive Auto, Global

dotnet new blazor -o {AppName} -int Auto -ai

With Authentication

Append `-au Individual` to any command above:

dotnet new blazor -o {AppName} -int Server -au Individual

`-au Individual` scaffolds ASP.NET Core Identity with SQLite (CLI) or SQL Server (Visual Studio). Identity pa