template-comparison

Template Comparison

This skill helps an agent compare 2+ dotnet new templates side by side so the user can pick the right one. It inspects each template's parameters and feature support and renders a comparison table.

When to Use

• User is deciding between similar templates (e.g., webapi vs webapp, blazor vs blazorwasm)
• User asks "which template should I use for X?"
• User wants to understand how two or more templates differ before creating a project

When Not to Use

• User wants to create a project — route to template-instantiation
• User wants to author or validate a custom template — route to template-authoring or template-validation
• User just needs to find or inspect a single template — route to template-discovery

Inputs

Input	Required	Description
Template short names	Yes	Two or more template short names to compare (e.g., webapi, webapp)
Comparison focus	No	Optional aspect to emphasize (auth, AOT, frameworks, interactivity)

Workflow

Evidence contract: a side-by-side table is useful only when every option claim is grounded in the currently installed templates. Run each --help command sequentially, capture the same requested dimensions for each template, and label an unavailable option as Not exposed rather than guessing or borrowing a flag from another template.

Decision contract: optimize the comparison for the user's stated decision, not table size. Cover every requested dimension, omit unrelated option rows, give a scenario-specific reason, and include one safe --dry-run command for the recommended starting point when it would make the recommendation actionable.

Step 1: Inspect each template

Run dotnet new <template> --help for each template being compared to collect its parameters (names, types, defaults, choices) and supported frameworks:

dotnet new webapi --help
dotnet new webapp --help

If a template is not installed, search for its provider and report the missing prerequisite. Install it only when the user asked you to modify the environment or approved the install.

Run --help calls sequentially. The template engine uses a global mutex, so running several dotnet new <template> --help commands concurrently can fail with a transient "mutex"/"persistence" error and empty output. Inspect templates one at a time; if a call fails, retry it once before moving on, and still produce the comparison from whatever parameter knowledge you have rather than ending with no answer.

Step 2: Build the comparison table

Produce a side-by-side table covering:

• Parameters — name, type, default, choices
• Feature support — auth, AOT, Docker, controllers, interactivity
• Available frameworks — e.g., net8.0, net9.0, net10.0
• Classifications — categories the template advertises (Web, API, Blazor, etc.)

Use one row per requested decision dimension and cite the observed option name in the cell. Do not fill a requested row with general framework knowledge when it is specifically about what the template generates or exposes.

When the user asks about generated dependencies without allowing project creation, inspect the installed template package's source .csproj files. --help and --dry-run do not reveal package references. Do not create temporary projects merely to inspect them, and do not guess current package IDs or test-platform defaults.

Example shape:

Aspect	webapi	webapp
Auth (--auth)	None, Individual, SingleOrg, Windows	None, Individual, SingleOrg, ...
AOT (--aot flag)	present if dotnet new webapi --help lists --aot	present if dotnet new webapp --help lists --aot
Controllers (--use-controllers)	Yes	n/a
Interactivity	n/a	n/a
Frameworks	net8.0 / net9.0 / net10.0	net8.0 / net9.0 / net10.0
Classifications	Web, WebAPI	Web, Razor Pages

Step 3: Recommend

End with a decisive Recommendation line — never leave the user with just a table. Format:

Recommendation: <template> — one sentence tying the choice to the user's stated scenario. (Pick the other if <condition>.)

Then link to template-instantiation to create it. A comparison that ends without naming a winner (or a clear "it depends on X") is incomplete — that indecision is what makes this skill tie with a plain answer.

Decision shortcuts for common pairs

Use these only for the recommendation, not as evidence of current parameter support. Still inspect with --help before filling the comparison table:

Pair	Default pick	Because
webapi vs webapp	webapi for a JSON/REST backend; webapp for server-rendered HTML/Razor Pages	webapi ships controllers/minimal APIs + OpenAPI, no UI
blazor vs blazorwasm	blazorwasm when offline / no server is required; blazor (Web App) for flexible server + client interactivity	Standalone WASM runs fully client-side, works offline
worker vs console	worker for long-lived/queue/background processing	Generic Host: DI, logging, config, graceful shutdown, IHostedService lifecycle
mvc vs webapp	webapp (Razor Pages) for page-focused apps; mvc for controller/view separation at scale	Razor Pages is lighter for CRUD-style pages

These constraints override the shorthand above:

• Choose mvc when the user explicitly anticipates a large application or shared controller logic, even if its first pages are CRUD-focused.
• Choose blazor with Server interactivity over webapp when rich interactive forms are central but useful HTML must arrive on the first response. Explain that the initial render is server-produced and that interactive components use the Blazor form/component model rather than Razor Pages PageModel.
• For offline support, choose blazorwasm and explain the PWA/service-worker requirement, cached-after-first-load behavior, and lack of a required live server for execution.
• For a durable queue processor, choose worker and tie the decision to Generic Host lifecycle, dependency injection, configuration, logging, graceful shutdown, and a real durable queue rather than an in-memory loop.

Validation

• [ ] Every template requested was inspected via dotnet new <template> --help
• [ ] The comparison covers parameters, feature support, frameworks, and classifications
• [ ] Differences relevant to the user's scenario are called out explicitly
• [ ] A recommendation (or clear trade-off) is provided
• [ ] Unsupported or absent options are labeled instead of guessed
• [ ] The final recommendation is a single decisive Recommendation: line

Common Pitfalls

Pitfall	Solution
Comparing uninstalled templates from memory	Install and inspect each template so the comparison reflects the real parameters and choices.
Assuming feature parity	Parameter names and feature support vary by template — confirm each with --help.
Comparing fundamentally different template types	Only compare templates that solve overlapping problems; note when they target different scenarios.

More Info

• dotnet new templates — built-in template reference
• dotnet new — CLI reference