Allow share template name for different languages

[kant2002]

Is your feature request related to a problem? Please describe.

I writing templates for F* language which provide exporting to F#. I want make consuming F* programs in .NET ecosystem to be as easy as possible. So I create template https://github.com/kant2002/fstarmsbuildsdk and by mistake do not change short template for template, but do change

1. Package identity
2. Language

Currently when I run dotnet new console --lang F* I receive following error message

Unable to resolve the template, the following installed templates are conflicting:
Identity                  Template Name  Short Name  Language  Author         Package

------------------------  -------------  ----------  --------  -------------  --------------------------------------------
FStarLang.Common.Console  Console App    console     F*        Andrii Kur...  FStarLang.DotNet.Common.ProjectTemplates.1.0
Microsoft.Common.Console  Console App    console     C#,F#,VB  Microsoft


Uninstall the template packages containing the templates to keep only one template from the list or add the template options which differentiate the template to run.

Describe the solution you'd like

Would be good that package resolution would take into account switch --lang here and resolve template not only on short name, but on short name + language.

Additional context

Other languages which may benefit from this

• C compiler for .NET https://github.com/fornever/cesium
• Zig probably https://github.com/vezel-dev/zig-sdk
• IronXXX family.
• Pascal.ABC http://pascalabc.net/en/

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[kant2002]

@marcpopMSFT is there something which external contributor can do to solve that? Or at least what stance SDK team has on this issue?

[marcpopMSFT]

This is on the templating side so routing to them. @dotnet/templating-engine-maintainers do you want templating issues still routed to the templating repo or leave them here since templating code is now in the repo?

[vlada-shubina]

For discussion:

• Allow to pick up certain template group or certain template to be run in case of ambiguity  #4135
• support disambiguation via --language (this issue)
• by default launch SDK templates

[kant2002]

@vlada-shubina should I jump to linked issue for discussion? From what I see --group and --identity is for disabmuguation of the templates within same language, or even narrower, withing same technology stack. Language is slightly stronger differentiator, so some concerns raised in dotnet/sdk#4135 seems to be not applicable. So I fear that I will only distract discussion in the linked issue.

[vlada-shubina]

Moving the issue to dotnet/templating for the planning purposes.

Short time solution - workaround
It is already possible to achieve the desired behavior, though a bit odd. The solution is to use the same groupIdentity as Microsoft template: here Microsoft.Common.Console. It makes the template appear in the same line/group in dotnet new.
You can check https://www.nuget.org/packages/Peachpie.Templates - they are already doing that.
@phenning please let us know if there are any concerns for Visual Studio here.

Medium time solution

• Implement Allow to pick up certain template group or certain template to be run in case of ambiguity  #4135 so the conflicts can be resolved by user.
• Allow disambiguation via --language (this issue)
• For the languages available from SDK, use SDK templates by default
• Update documentation on group identity: Groupidentity not validated, improve documentation about requiredness of template.json fields #2384

Long time solution

• Rename common groupIdentity from Microsoft.* to DotNet.* #5357 - rename group identities so they are associated with DotNet and not Microsoft. This is not an easy task due to backward compatibilities.

[phenning]

@vlada-shubina The issue though there is already an F# console template. If this new template were to have the same group identity, I believe it could hide the built in SDK template depending on the precedence value. Visual Studio would end up using one or the other, not both.

[baronfel]

@phenning this new template would be for F-Star, a proof language that is distinct from F# :)

[kant2002]

Are Visual Studio taking language into account when displaying template ? Because I clearly see F* as separate language in VS UI.

[phenning]

OK, my aging eyes just noticed it was * and not #. Apologies ;)

I just did some testing on a mock template. You do need to define the "Framework" symbol just like the console template does due to the a bug in the current logic we have that groups the templates together. The bug results in the template being shown, but uncreatable from Visual Studio. There is currently, a bug where we don't handle the case with some language templates within a group have a Framework symbol and others not.

Also, I'm assuming there is a project system that knows how to handle whatever .*proj file is output by the template. There may be further refinements that may need to happen to the templates metadata to hide if the requisite components are not present.

[phenning]

(Opened AzDO 1637898 to track the mentioned bug above)