Allow to pick up certain template group or certain template to be run in case of ambiguity

[vlada-shubina]

At the moment 2 cases for ambiguity may happen during template instantiation:

• different template groups may have same short name
• different templates in one group may have same precedence and it is not possible to determine the one to be run

Those cases may be solved by uninstalling one of the packages in template groups are coming from different packages, however if they are coming from single one the situation cannot be resolved.

Suggesting the following options to resolve these conflicts:

• --group allows to specify group identity to run
• --identity allows to specify template identity to run

The error cases should be modified as following: (ambiguous group) Unable to resolve the template, these templates matched your input:

Name	Short name	Group
Template 1	short	Group.Identity1
Template 2	short	Group.Identity2

To run specific template, specify its group using --group option. dotnet new short --group Group.Identity1.

(ambiguous template) Unable to resolve the template, these templates matched your input:

Name	Short name	Identity
Template 1	short	Templ.Identity1
Template 2	short	Templ.Identity2

This may happen due to authoring error or ambiguous parameter set. To run specific template, specify the identity using --identity option. dotnet new short --identity Templ.Identity1

[bekir-ozturk]

I like how explicit -group and -identity options are. At the same time, I think this may result in too much typing.

For instance, to instantiate editorconfig template from Boxed.Templates, one would need to type: dotnet new editorconfig --identity Dotnet.Boxed.editorconfig.CSharp which is much longer compared to dotnet new editorconfig

The same happens with --group option.

---

Maybe as an alternative, we can add a postfix to conflicting short names. For instance, if you have two templates with short name editorconfig, one could be renamed to editorconfig2. Numbers could be added according to the alphanumeric ordering of template package identifiers. If you delete/update template packages, the ordering and hence the short names may change.

[baronfel]

Another option would be to support the template identity as the main parameter to dotnet new, in addition to the template short name. This would allow for a greater degree of specificity and not have the duplication inherent in the dotnet new <template short name> --identity <template identity> example. One downside here is that the template identity may not be unique enough, or in some cases may be the same as the short name, so better tools for template authors to detect and fix these scenarios might be required.

[sayedihashimi]

One downside here is that the template identity may not be unique enough, or in some cases may be the same as the short name, so better tools for template authors to detect and fix these scenarios might be required.

Template authors shouldn't be doing this. Instead of working around it, let's error when a user tries to install a template with a conflict on identity. I can run my template analyzer to see if there are any duplicate IDs being used. I'll try to do that soon. I'm currently in the middle of some changes so I may need to wrap that up before hand.

Here is a JSON file (renamed as .txt to support GH) with all the templates that I could find. Will look for dupes later. template-report.json.txt

[sayedihashimi]

I ran my tool to identify templates that re-use the identity value across templates.

I only found 4 IDs that are actually being used in different templates.

template-pack-id						identity
Microsoft.DotNet.Web.ItemTemplates		Microsoft.Web.Grpc.Protobuf
Microsoft.DotNet.Web.ItemTemplates.6.0	Microsoft.Web.Grpc.Protobuf
VijayAnand.BlazorTemplates				VijayAnand.WindowsForms.Blazor
VijayAnand.BlazorTemplates				VijayAnand.Wpf.Blazor

My report did include the following as well, but that is due to this bug https://github.com/dotnet/templating/issues/4140. Those are listed below.

template-pack-id						identity
SpecFlow.Templates.DotNet				SpecFlowTemplates.DotNET.Item.SpecFlowFeature
SpecFlow.Templates.DotNet				SpecFlowTemplates.DotNET.Item.SpecFlowConfiguration
SpecFlow.Templates.DotNet				SpecFlowTemplates.DotNET.Item.SpecFlowPlusProfile
SpecFlow.Templates.DotNet				SpecFlowTemplates.DotNET.Project
SpecFlow.Templates.DotNet				SpecFlowTemplates.DotNET.Item.SpecFlowFeature
SpecFlow.Templates.DotNet				SpecFlowTemplates.DotNET.Item.SpecFlowConfiguration
SpecFlow.Templates.DotNet				SpecFlowTemplates.DotNET.Item.SpecFlowPlusProfile
SpecFlow.Templates.DotNet				SpecFlowTemplates.DotNET.Project
Threenine.ApiProject					Threenine.ApiProject
Threenine.ApiProject					Threenine.ApiProject
VijayAnand.Wpf.Blazor					VijayAnand.Wpf.Blazor
VijayAnand.WindowsForms.Blazor			VijayAnand.WindowsForms.Blazor
Laconic.AppTemplate					Laconic.AppTemplate
Laconic.AppTemplate					Laconic.AppTemplate
VijayAnand.BlazorTemplates				VijayAnand.WindowsForms.Blazor
VijayAnand.BlazorTemplates				VijayAnand.Wpf.Blazor
E5R.Architecture.Template				E5R.Architecture.Template.FullSolution
E5R.Architecture.Template				E5R.Architecture.Template.FullSolution
sayedha.templates						Sayedha.Templates.CliTool
sayedha.templates						Sayedha.Templates.IdeHostJson
sayedha.templates						Sayedha.Templates.TemplateJson
sayedha.templates						Sayedha.Templates.TemplatePackJson
sayedha.templates						Sayedha.Templates.CliTool
sayedha.templates						Sayedha.Templates.IdeHostJson
sayedha.templates						Sayedha.Templates.TemplateJson
sayedha.templates						Sayedha.Templates.TemplatePackJson

[baronfel]

There are three sides to this:

• Authoring
  • We should add validation to the templating build tasks that we already have - when Packing a template, we could check against the search json for duplicate identityies to help the user not upload garbage data. Probably default this to not run when Deterministic is true, because we don't want to do network I/O on reproducible builds
• Installing
  • We should error when installing a template with an identity conflict (as such a template would be unusable). This should be overridable by the user via a --force flag similar to our other overrides on installation (e.g. the updated package templates override we added recently)
• Cleanup
  • We should reach out to the template owners that @sayedihashimi has noted above and work with them to deduplicate their identities ahead of any changes to the user experience here

[sayedihashimi]

For the Authoring case, I think this should be a warning and not an error.