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.
This skill creates .NET projects from templates using dotnet new CLI commands, with guidance for parameter validation, Central Package Management adaptation, and multi-project composition.
Directory.Packages.propstemplate-discovery skilltemplate-authoring skilldotnet add package directly| Input | Required | Description |
|---|
| Template name or intent | Yes | Template short name (e.g., webapi) or natural-language description |
| Project name | Yes | Name for the created project |
| Output path | Recommended | Directory where the project should be created |
| Parameters | No | Template-specific parameters (e.g., --framework, --auth, --aot) |
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.
Check the existing solution structure before creating:
Directory.Packages.props.csproj filesglobal.json pinning the SDK?This ensures the new project is consistent with the workspace.
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
Use dotnet new with the template name and all parameters:
dotnet new webapi --name MyApi --output ./src/MyApi --framework net10.0 --auth Individual
| 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:
.csproj for inline <PackageReference> versionsDirectory.Packages.props as <PackageVersion> entriesVersion attributes from the .csprojFor 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
Install or uninstall template packages:
dotnet new install Microsoft.DotNet.Web.ProjectTemplates.10.0
dotnet new uninstall Microsoft.DotNet.Web.ProjectTemplates.10.0
dotnet builddotnet build at the solution levelDirectory.Packages.props has the new entriesdotnet build.csproj has no version attributes and Directory.Packages.props has matching entries| Pitfall | Solution |
|---|---|
| Not checking for CPM before creating a project | If Directory.Packages.props exists, dotnet new creates projects with inline versions that conflict. After creation, move versions to Directory.Packages.props and remove them from .csproj. |
| Creating projects without specifying the framework | Always specify --framework when the template supports multiple TFMs to avoid defaulting to an older version. |
| Not adding the project to the solution | After creation, run dotnet sln add to include the project in the solution. |
| Not verifying the project builds | Always run dotnet build after creation to catch missing dependencies or parameter issues early. |