How to specify default Language for a multi-language Template ?

[bartelink]

I've got a template which has a C# and an F# impl under the same groupIdentity.

No amount of searching can tell me why its picking the wrong default language.

is there a way for me to indicate in the template.json which language should win ?

[seancpeters]

The default language is a template engine host defined value. For example, in the CLI, C# is the default language. It's not something that is specified in the template configuration. So when invoking your template from the CLI, if the -lang flag & value are not specified, C# will always win.

[bartelink]

Thanks for the response; that's unfortunate -- the fact the -l presents a lang list with a default per row had me thinking it might be controllable. I guess where there are 2 langs and neither is C# the selection needs to be presented.

I'll close on the basis this is not likely to be a widespread need (but to be clear: for my use case, I definitely want the optimal language for my template to be chosen ;) so I'd definitely be interested in the feature)

💭 Maybe I just need to forgo the groupIdentity and put the lang name in the template...

[seancpeters]

What would your criteria be for the optimal language choice?

In general, the CLI tries to figure out which template to run by first matching the template name. If there are still multiple templates to choose from, then the user specified parameters are considered. If exactly one template matches, it's used. If multiple templates still match, only then is the language considered - if the user specified a language it also has to match, if not, then the template matching the default language is selected to run.

As an example in the CLI, consider a template called "example", that has a C# and an F# version.
The C# template has a parameter named --foo (which the F# template does not have)
The F# template has a parameter named --bar (which the C# template does not have)

Running dotnet new example --foo <somevalue> will cause the C# template to be chosen, because --foo is only valid for the C# version.

Running dotnet new example --bar <somevalue> will cause the F# template to be chosen, because --bar is only valid for the F# version.

Running dotnet new example --foo x --bar y will cause neither template to be selected to run, since there are invalid parameters for both the C# and the F# templates. A usage message will be displayed.

[bartelink]

Thanks for detailing the lookup process - nice to know all that logic is in there.
The work in question is jet/dotnet-templates#5 - I have had to do this as a workaround.

While I have you... VS is not showing the template in it's list - or at least I can't seem to persuade it to. Given its a runnable application template and hence arguably could count as a solution template - is there a way to tag it as such ? (Rider shows it...)

[seancpeters]

Getting templates to show up in Visual Studio is a bit more complex than just installing them in your dotnet new instance. This #1209 has info and links for how to get your template to show up in Visual Studio.

[bartelink]

Thanks Sean - that's all very helpful; thanks for the great service!

[bartelink]

FWIW, for now I've done two separate templates not under a common groupId.

I do look forward to a point in time where dotnet new -i can provision all 3/4 IDEs I've got on my Mac without any busywork. The biggest pain is the conceptual overhead of having to explain/justify in the readme for a project that you do this for dotnet new and whole other thing for the most commonly used thing.

If I'm forced to pick one (I'm not, any more than you guys are, but I'm using the same "not enough traffic" argument to justify my laziness ;) ), it's going to be dotnet new every time as it's sooo clean to be able to have a quickstart consisting of

1. dotnet tool install Equinox.Tool

2. dotnet new -i Equinox.Templates

3. dotnet new eqxweb --todo

4. dotnet run -p Web

ASIDE: a better job needs to be done on consistency - the -i vs install should not be per-tool, and it'd really be nice for the -p clutter to go away from what's for me the most common usage of dotnet run. if

1. dotnet new install was special cased by outlawing the template name install
2. dotnet run Web/ (note the trailing /) implied a -p
   that could be achieved, and one can do

dotnet tool install Equinox.Tool
dotnet new install Equinox.Templates
dotnet new eqxweb --todo
dotnet run Web/

instead of forcing beginners to jump through hoops typing:

dotnet tool install Equinox.Tool
dotnet new -i Equinox.Templates
dotnet new eqxweb --todo
dotnet run -p Web

(and then telling them "go click on this thing to get it in VS")

This sort of stuff is frequently given the amount of love on other platforms, and it really pays off (same with dotnet tool list vs dotnet new -l)

Picture the difference if I'm trying to present a library thing that has a Tool and Templates with and without having to click to install the templates into VS and having to explain and/or gloss over highly arbitrary inconsistencies in command line syntax which can be avoided