[CLI] Add --framework option to aspire new

[matthebrown]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change.

Fixes #9931

Checklist

• Is this feature complete?
  • Yes. Ready to ship.
  • No. Follow-up changes expected.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
    • If yes, did you have an API Review for it?
      • Yes
      • No
    • Did you add <remarks /> and <code /> elements on your triple slash comments?
      • Yes
      • No
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
    • If yes, have you done a threat model and had a security review?
      • Yes
      • No
  • No
• Does the change require an update in our Aspire docs?
  • Yes
    • Link to aspire-docs issue (consider using one of the following templates):
      • New (or update) doc-idea template
      • New breaking-change template
      • New diagnostic template
  • No

[Copilot]

Pull Request Overview

This PR adds a --framework option to the aspire new command so that users can specify a target framework when scaffolding new projects.

• Introduces a nullable --framework CLI option and propagates it through parsing and into the dotnet new invocation.
• Updates the IDotNetCliRunner interface, its real implementation, and the test stub to include the optional framework parameter.
• Adds resource entries and translations for the new argument, and a test verifying that the framework value is passed correctly.

Reviewed Changes

Copilot reviewed 19 out of 20 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/Aspire.Cli/Commands/NewCommand.cs	Added --framework CLI option with description
src/Aspire.Cli/Templating/DotNetTemplateFactory.cs	Read framework from parse result and pass it to the runner
src/Aspire.Cli/DotNetCliRunner.cs	Extended NewProjectAsync to include framework in CLI args
tests/Aspire.Cli.Tests/TestServices/TestDotNetCliRunner.cs	Adjusted test stub signature to accept the framework parameter
tests/Aspire.Cli.Tests/Commands/NewCommandTests.cs	Added test for framework propagation
src/Aspire.Cli/Resources/NewCommandStrings.resx & .xlf	Added FrameworkArgumentDescription and translations

Files not reviewed (1)

• src/Aspire.Cli/Resources/NewCommandStrings.Designer.cs: Language not supported

Comments suppressed due to low confidence (3)

tests/Aspire.Cli.Tests/TestServices/TestDotNetCliRunner.cs:18

• The NewProjectAsyncCallback delegate signature omits the extraArgs parameter, so any additional CLI flags are ignored in tests; consider adding a string[] extraArgs parameter after framework to mirror the production signature.

    public Func<string, string, string, string?, DotNetCliRunnerInvocationOptions, CancellationToken, int>? NewProjectAsyncCallback { get; set; }

src/Aspire.Cli/Templating/DotNetTemplateFactory.cs:200

• [nitpick] Using a literal string to retrieve the option value can be fragile; consider storing the Option<string?> instance in a field and using parseResult.GetValueForOption(frameworkOption) to tie it directly to the declared option.

            var framework = parseResult.GetValue<string?>("--framework");

tests/Aspire.Cli.Tests/Commands/NewCommandTests.cs:574

• You added a test for when a framework is specified; consider adding a complementary test to verify that, when no --framework flag is provided, the default (null or empty) framework value is passed through correctly.

    [Fact]

[davidfowl]

I'm not sure we want this change.

[mitchdenny]

@davidfowl I was talking to @DamianEdwards and @maddymontaquila about this. I think we resolved that did want to ask what the target framework should be somewhere in the flow of questions. We would want the latest stable build to be the default, but allow us to choose 8.0 or 10.0 preview too.

[davidfowl]

Did we decide that we are going to flow options wholestale to the template provider?

[mitchdenny]

Well, I think that there are two things here. I think we agreed that aspire new should really be primarily an interactive experience. So to that end adding the --framework option goes against that - however prompting for the framework version would be good, especially being able to choose version 10 (which wouldn't be the default - but still desirable to choose).

[davidfowl]

I'm ok with prompting for the framework. I was more worried that we didn't have a plan for flowing arguments cleanly.

[davidfowl]

@mitchdenny this is missing from the current templates in aspire new

[mitchdenny]

We should pass this argument through via extraArgs.

[mitchdenny]

We need to add prompting for selecting the framework for when people execute aspire new without arguments. interactive is the primary interaction model for aspire new.

[davidfowl]

@matthebrown Sorry this PR went stale. If we did this it would be part of the interactive flow but not an argument to new

[davidfowl]

Closing in favor of #11232