search

dotnet / templating

This repo contains the Template Engine which is used by dotnet new
https://docs.microsoft.com/dotnet/
MIT License
1.61k stars 368 forks source link

Allow share template name for different languages #5358

Open kant2002 opened 2 years ago

kant2002 commented 2 years ago

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

dotnet-issue-labeler[bot] commented 2 years ago

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 commented 1 year ago

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

marcpopMSFT commented 1 year ago

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 commented 1 year ago

For discussion:

kant2002 commented 1 year ago

@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 commented 1 year ago

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

Long time solution

phenning commented 1 year ago

@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 commented 1 year ago

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

kant2002 commented 1 year ago

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

phenning commented 1 year ago

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 commented 1 year ago

(Opened AzDO 1637898 to track the mentioned bug above)