Summary
When using dotnet_project (action: New), some templates do not accept certain target frameworks (e.g., net10.0). Today, this constraint is often only discoverable by attempting creation and failing.
We should improve UX by exposing template capabilities (allowed TFMs and key options/constraints) via a discoverability call before project creation.
Problem
- Users/agents may default to the latest TFM (e.g.,
net10.0).
- Some templates only support certain TFMs (or have custom rules), causing
dotnet new to fail.
- The current workflow becomes: try → fail → parse error → retry.
Desired UX
A consumer should be able to:
- Ask “what frameworks/options does this template support?”
- Choose a valid TFM/options combination.
- Call
dotnet_project New successfully on the first attempt.
Proposal
Option A (recommended): Extend dotnet_sdk TemplateInfo / add a new action
- Add an action such as
dotnet_sdk (action: TemplateCapabilities) or extend TemplateInfo output to include a capabilities section.
- Capabilities could include:
supportedFrameworks: list of known supported TFMs (when determinable)
defaultFramework: TFM (if applicable)
parameters: structured options (name, type, required, allowed values)
constraints: structured constraints (e.g., “only supports net8.0+”, “not supported on macOS”, etc.)
source: whether data came from Template Engine API vs CLI parsing
Option B: Provide a validation helper for dotnet_project New
- Add a
validateOnly: true flag or a dotnet_project action like NewValidate that:
- validates the requested template + framework + options
- returns structured suggestions if invalid (allowed TFMs, closest match)
Implementation notes
- Template Engine metadata may not always expose TFMs explicitly; we may need to:
- parse
dotnet new <template> --help output, and/or
- infer allowed TFMs based on template parameters and known conventions.
- Keep it conservative and clearly indicate confidence/source.
Tests
- Add unit tests for:
- machine-readable schema includes
capabilities fields
- behavior when TFMs are determinable vs unknown
- validation errors include suggested TFMs/options
- Add scenario test (opt-in) demonstrating:
- call capabilities/info
- select valid TFM
- successfully create project
Acceptance criteria
- There is a supported “discover capabilities” call that surfaces template framework constraints/options in machine-readable form.
dotnet_project New failures include structured suggestions when framework mismatch is detected.
- Docs show the recommended flow: TemplateInfo/capabilities → New.
Summary
When using
dotnet_project(action:New), some templates do not accept certain target frameworks (e.g.,net10.0). Today, this constraint is often only discoverable by attempting creation and failing.We should improve UX by exposing template capabilities (allowed TFMs and key options/constraints) via a discoverability call before project creation.
Problem
net10.0).dotnet newto fail.Desired UX
A consumer should be able to:
dotnet_projectNew successfully on the first attempt.Proposal
Option A (recommended): Extend
dotnet_sdkTemplateInfo / add a new actiondotnet_sdk(action:TemplateCapabilities) or extendTemplateInfooutput to include a capabilities section.supportedFrameworks: list of known supported TFMs (when determinable)defaultFramework: TFM (if applicable)parameters: structured options (name, type, required, allowed values)constraints: structured constraints (e.g., “only supports net8.0+”, “not supported on macOS”, etc.)source: whether data came from Template Engine API vs CLI parsingOption B: Provide a validation helper for
dotnet_project NewvalidateOnly: trueflag or adotnet_projectaction likeNewValidatethat:Implementation notes
dotnet new <template> --helpoutput, and/orTests
capabilitiesfieldsAcceptance criteria
dotnet_project Newfailures include structured suggestions when framework mismatch is detected.