Guides creation and validation of custom dotnet new templates.
Template Instantiation
Creates .NET projects from templates with validated parameters, smart defaults, Central Package Management adaptation, and latest NuGet version resolution. USE FOR: creating new dotnet projects, scaffolding solutions with multiple projects, installing or uninstalling template packages, creating projects that respect Directory.Packages.props (CPM), composing multi-project solutions (API + tests + library), getting latest NuGet package versions in newly created projects. DO NOT USE FOR: finding or comparing templates (use template-discovery), authoring custom templates (use template-authoring), modifying existing projects or adding NuGet packages to existing projects.
Workflow
Step 1: Resolve template and parameters
If the user provides a natural-language description, map it to a template short name (see the keyword table in the template-discovery skill). If they provide a template name, proceed directly.
Use dotnet new <template> --help to review available parameters, defaults, and types for any parameters the user did not specify.
Step 2: Analyze the workspace
Check the existing solution structure before creating:
- Is Central Package Management (CPM) enabled? Look for
Directory.Packages.props - What target frameworks are in use? Check existing
.csprojfiles - Is there a
global.jsonpinning the SDK?
This ensures the new project is consistent with the workspace.
Step 3: Preview the creation
Use dotnet new <template> --dry-run to show the user what files would be created. Confirm before proceeding.
dotnet new webapi --name MyApi --framework net10.0 --dry-run
Step 4: Create the project
Use dotnet new with the template name and all parameters:
dotnet new webapi --name MyApi --output ./src/MyApi --framework net10.0 --auth Individual
#### Common parameter combinations
| Template | Parameters | Example | |----------|-----------|---------| | webapi | --auth (None, Individual, SingleOrg, Windows), --aot (native AOT) | dotnet new webapi -n MyApi --auth Individual --aot | | webapi | --use-controllers (use controllers vs minimal APIs) | dotnet new webapi -n MyApi --use-controllers | | blazor | --interactivity (None, Server, WebAssembly, Auto), --auth | dotnet new blazor -n MyApp --interactivity Server | | grpc | --aot (native AOT) | dotnet new grpc -n MyService --aot | | worker | --aot (native AOT) | dotnet new worker -n MyWorker --aot |
Note: Use dotnet new <template> --help to see all available parameters for any template.
After creation, if the workspace uses CPM:
- Check
.csprojfor inline<PackageReference>versions - Move version attributes to
Directory.Packages.propsas<PackageVersion>entries - Remove
Versionattributes from the.csproj
Step 5: Multi-project composition (optional)
For complex structures, create each project sequentially and wire them together:
dotnet new webapi --name MyApi --output ./src/MyApi
dotnet new xunit --name MyApi.Tests --output ./tests/MyApi.Tests
dotnet add ./tests/MyApi.Tests reference ./src/MyApi
dotnet sln add ./src/MyApi ./tests/MyApi.Tests
Step 6: Template package management
Install or uninstall template packages:
dotnet new install Microsoft.DotNet.Web.ProjectTemplates.10.0
dotnet new uninstall Microsoft.DotNet.Web.ProjectTemplates.10.0
Step 7: Post-creation verification
- Verify the project builds:
dotnet build - If added to a solution, verify
dotnet buildat the solution level - If CPM was adapted, verify
Directory.Packages.propshas the new entries
Related skills
Helps find, inspect, and compare .NET project templates.
Validates custom dotnet new templates for correctness before publishing.