Allow `dotnet new console -tf net472` to specify target framework of the new project

[KirillOsenkov]

Right now there's no easy way to create a new .csproj targeting a different framework.

Add a way to specify which target framework(s) to use for the newly created project.

[sfoslund]

@KirillOsenkov @KathleenDollard correct me if I'm wrong but I believe the --framework option allows you to do this. Transferring to the template engine, who owns dotnet new.

[vlada-shubina]

--framework has restricted list of values ( .NET Core.NET tfms) . Targeting .NET framework is not intended.

For some templates, including console, it is possible to override target framework using --target-framework-override option, however there is no validation. It just creates the same template having the value of --target-framework-override passed as TargetFramework in csproj. This feature is hidden. https://github.com/dotnet/templating/issues/3261

Tagging @baronfel to discuss support of .NET Framework TFMs in .NET SDK.

[KirillOsenkov]

Note that I'm looking for a low-friction solution here. While --target-framework-override is nice and I didn't know about it, it has discoverability issues, and is plainly long to type. Remember, the goal of dotnet new is to simplify new project creation. If it is easier to just type up the .csproj by hand or edit the .csproj manually, dotnet new has lost its purpose as a utility to save users time.

We should definitely add net472 and other desktop tfms to the --framework option, as well as see whether we can introduce a shorter shortcut such as -f, again, to save users some typing.

Thanks!

[vlada-shubina]

-f is already available as alias for --framework. We are also working on getting tab completion work now, including template options.

[baronfel]

Nothing groundbreakingly new here, but here's where I see this issue currently:

There's a bit of a hurdle we've got to overcome here:

• SDKs no longer include every TFM for different templates, so knowing the full set of TFMs that we have a particular template for is harder,
• the engine itself only advertises TFMs that it has templates for for completions,
• the engine itself uses the --framework parameter as a pivot to determine which template to choose (see point 1), not as the TFM MSBuild property

Untangling these will be difficult, but to me the primary problem from a UX perspective is the overloaded use/meaning of the parameter.

[baronfel]

We're tentatively looking at solving the TFM mismatches by a new template generator specifically for .NET projects, instead of the generic default generator. This will be tracked in this epic.