create-blazor-project

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

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

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

Interactive Server, Global

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

Interactive WebAssembly, Per-Page

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

Interactive WebAssembly, Global

Interactive Auto, Per-Page

Interactive Auto, Global

With Authentication

Append -au Individual to any command above:

-au Individual scaffolds ASP.NET Core Identity with SQLite (CLI) or SQL Server (Visual Studio). Identity pages are always static SSR — they do not use interactive render modes.

The blazor template only supports -au Individual. For organizational auth (Microsoft Entra ID, Azure AD B2C), scaffold with -au Individual first, then replace the Identity provider with Microsoft.Identity.Web / OIDC middleware and configure the tenant in appsettings.json.

What the Template Creates

Single project (Static SSR, Server)

Two projects (WebAssembly, Auto)

Rule: Components using InteractiveWebAssembly or InteractiveAuto must live in the .Client project. They can reference shared code but cannot reference server-only types (EF DbContext, server-side services).

Program.cs Wiring

The template generates the correct Program.cs for the chosen mode. Verify these registrations match your intent:

Static SSR Only

Server (per-page or global)

WebAssembly (per-page or global)

Create Project AGENTS.md

After scaffolding, create an AGENTS.md file in the project root (next to the .csproj). For two-project setups, put it in the server project root.

Pick the matching template from assets/agents-md/ based on the chosen mode:

Copy the template contents into the project's AGENTS.md and replace every {AppName} with the actual project name. If auth was scaffolded (-au Individual), add an ## Authentication section noting that ASP.NET Core Identity is configured and that Identity pages under Components/Account/ are always static SSR — do not add @rendermode to them.

After scaffolding the project and creating AGENTS.md, continue implementing the features the user requested. Remove default template pages (Counter, Weather) and replace them with the actual application pages.

Auto (per-page or global)

App.razor — Global vs Per-Page

The difference between global and per-page interactivity is entirely in App.razor:

Per-page (default)

No @rendermode on <Routes> or <HeadOutlet>. Individual pages opt in.

Global

Replace InteractiveServer with InteractiveWebAssembly or InteractiveAuto as appropriate.

After Scaffolding

1. Verify it builds: dotnet build
2. Run it: dotnet run (in the server project if two-project setup)
3. Add your first page: Create a .razor file in Components/Pages/ (server project) or Pages/ (.Client project for WebAssembly components)

Don'ts

• Don't use dotnet new blazorwasm — that creates a standalone WebAssembly SPA without server-side rendering. Use the blazor template with -int WebAssembly instead.
• Don't manually add AddInteractiveServerComponents() to a project created with -int None and expect it to work — you also need the @rendermode directives and potentially App.razor changes. Re-scaffold if the mode needs to change fundamentally.
• Don't put WebAssembly-targeted components in the server project — they'll work during prerender but fail after handoff.