Skip to content

v2: Improve dotnet_project New template discoverability (expose allowed TFMs/options before failing) #290

@jongalloway

Description

@jongalloway

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:

  1. Ask “what frameworks/options does this template support?”
  2. Choose a valid TFM/options combination.
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions