Templating: dotnet new for --frameworks targeting the .NET Framework

[wli3]

_From @rendmath on October 14, 2017 23:3_

Steps to reproduce

dotnet new console --framework net461

Expected behavior

dotnet creates a console (or other type of) application targeting the specified version of the .NET Framework.

Actual behavior

Error message:
Error: Invalid parameter(s):
--framework net461
'net461' is not a valid value for --framework (Framework).
Run dotnet new console --help for usage information.
See https://aka.ms/dotnet-install-templates to learn how to install additional template packs.

Environment data

dotnet --info output:

.NET Command Line Tools (2.1.0-preview1-007363)

Product Information:
Version: 2.1.0-preview1-007363
Commit SHA-1 hash: ee6707ced0

Runtime Environment:
OS Name: Windows
OS Version: 10.0.15063
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.0-preview1-007363\

Microsoft .NET Core Shared Framework Host

Version : 2.1.0-preview2-25616-02
Build : 8aa34a95bad481e1b5e4c8286e5cb2d7cb6ed943

_Copied from original issue: dotnet/cli#7840_

[wli3]

_From @rendmath on October 14, 2017 23:30_

Current workaround: a PowerShell function to change the \

function ChangeTargetFramework($project, $targetFramework)
{
    [xml]$projectXml = Get-Content $project;
    $projectXml.Project.PropertyGroup.TargetFramework = $targetFramework;
    $projectXml.Save((Join-Path (Get-Location) $project))
}

[mlorbetske]

The --framework switch has a list of choices that are valid for the set of templates that are installed, it does not allow arbitrary values. To use a value for framework that isn't explicitly allowed, but you're certain it will work anyway, use the --target-framework-override parameter.

Ex. dotnet new console --target-framework-override net461

[rendmath]

Exactly what I need, thank you.

I understand that you don't have unlimited resources, and that maintaining templates for the "legacy" .NET Framework might not be high in your list of priorities.

Nevertheless, many people are still using the .NET Framework, and will continue to use it even for greenfield development, at least until libraries like EF Core are brought up to some kind of feature parity with their .NET Framework predecessor.

So it feels like it would be useful to document this switch (though with a very explicit warning that the user is entirely responsible for the outcome).