"dotnet new mvc -lang f#" failing with switch "-au" on Windows 10 64 bit

[mlorbetske]

From @wli3 on April 19, 2018 23:53

From @MikeGale on September 21, 2017 6:47

Steps to reproduce

1. dotnet new mvc -lang F# -o AspNetCoreFS -au Individual

Expected behavior

Generate an F# mvc web site. (--help says that this can be done.)

Actual behavior

Fails with error:

Invalid input switch:
  -au
  Individual
Run dotnet new mvc --help for usage information.
See https://aka.ms/dotnet-install-templates to learn how to install additional template packs.

(CSharp mvc is generated as expected.)

Environment data

dotnet --info output:

.NET Command Line Tools (2.0.0)

Product Information: Version: 2.0.0 Commit SHA-1 hash: cdcd1928c9

Runtime Environment: OS Name: Windows OS Version: 10.0.14393 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\2.0.0\

Microsoft .NET Core Shared Framework Host

Version : 2.0.0 Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

Copied from original issue: dotnet/cli#7687

Copied from original issue: dotnet/templating#1515

[mlorbetske]

From @wli3 on April 19, 2018 23:53

From @am11 on September 21, 2017 12:24

It seems like if any of the user supplied argument is meant for cli's top-level command (dotnet-new in this case), the argument parser considers all the rest of the arguments are meant for top-level command as well. In this case -au Individual was actually meant for mvc sub-command.

In case of dotnet new mvc -au Individual (which is supposed to be a shorthand of dotnet new --language C# mvc -au Individual), the CLI propagates the argument handling to sub-command nicely.

dotnet new without -lang == dotnet new -lang C#, but args parsing rules that are applied to the shorthand are inconsistent. Would be nice if CLI simply pass-through the unknown arguments to subcommand in all cases or have the consistent behavior one way the other.

@MikeGale, the workaround is to use the argument separator -- (with spaces around), e.g.

dotnet new mvc -lang F# -- -au Individual --no-restore

[mlorbetske]

From @wli3 on April 19, 2018 23:53

From @livarcocc on September 21, 2017 16:9

@wli3 can you take a look?

@mlorbetske @seancpeters FYI

[mlorbetske]

From @wli3 on April 19, 2018 23:54

CLI passed all args to template engine. The error is at template engine stack.

[mlorbetske]

These options aren't actually supported by the F# flavor of the MVC template. dotnet new mvc -lang F# -h reveals this. Moving this to aspnet/templating to see if they've got plans on adding authentication options to the F# templates

[mkArtakMSFT]

@javiercn, what can we do here?

[javiercn]

@mkArtakMSFT Nothing if the auth option is not supported. @cartermp the PM for the F# team owns the F# version of the ASP.NET templates.

[cartermp]

Until authentication is handled by a library call, I don't think we'll get to this for the F# templates.

[javiercn]

@cartermp Authentication is handled by a library call as part of our 2.1 release. https://blogs.msdn.microsoft.com/webdev/2018/03/02/aspnetcore-2-1-identity-ui/ You can use the default Identity UI that comes in a library. Take a look at it and evaluate if that's something you want to do to enable these types of scenarios for the F# templates.

[cartermp]

Is services.AddDefaultIdentity<IdentityUser>() considered valid for API template as well, or just the MVC template? Happy to add it to both, but we only ship the Empty and API templates in VS, so if it's best to add it to the API template as well, we may need to kick off an insertion in VS at some point.

[javiercn]

@cartermp Just the MVC/Razor templates. We don't use Identity in API templates

[javiercn]

Closing this as by design