dotnet/templating

dotnet new giraffe fails after latest update

livarcocc opened this issue · 5 comments

From @dustinmoris on December 16, 2017 22:27

Steps to reproduce

dotnet new giraffe

or as @cartermp demo'd in his blog post:

dotnet new giraffe -o GiraffeSample

Expected behavior

The CLI should identify that the giraffe template only supports F# as language and therefore successfully create an F# Giraffe application without asking the user to specify the additional -lang parameter.

Actual behavior

The command fails and shows help for dotnet new. This is a regression bug as it worked as expected in previous versions.

Environment data

dotnet --info output:

.NET Command Line Tools (2.0.3)

Product Information:
 Version:            2.0.3
 Commit SHA-1 hash:  eb1d5ee318

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.13
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/2.0.3/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.3
  Build    : a9190d4a75f4a982ae4b4fa8d1a24526566c69df

Copied from original issue: dotnet/cli#8257

Would like to clarify that this affects any template that by default supports any .NET language other than C#. Two immediate examples that come to mind are the templates for Giraffe and the SAFE Stack. Both have dotnet cli templates that at the moment do not work unless the language option for F# is supplied. The Giraffe repo already has two issues related to this: giraffe-fsharp/Giraffe#173, giraffe-fsharp/Giraffe#170.

...also, what is the thinking around letting devs change the default language at the CLI level so that -lang f# or -lang vb gets used automatically and F# and VB devs don't have to always type out the lang option for multi-lang templates. I think I remember mention of this in the early days, wondering if this is still viable...

Fixed with PR #1375

I'm running into this issue in 2.1.4... has this fix been shipped?

@csmager this fix will ship in the CLI that carries the first preview of the 2.1.0 runtime

Thanks - was evidently confused by SDK vs runtime versions! Glad it's not something I'm doing wrong...