Enable automatic install of templates on first use

[satyajit-behera]

trafficstars

Was thinking, it would enable a lot of ease and usage if the templates can be used without installing it using dotnet new. Can we just use those templates directly from the nugets or a folder to create those items derived from the templates. It may be available now, not sure, but I could not see any available solution for the same.

---

Audience: dotnet CLI users

Background

Now to instantiate any template you need to install the package containing it first. The packages are not updated automatically, and it's user responsibility to keep the up-to-date. To check updates the user needs to use update command or will be prompted only after outdated template is created. In many cases, when acquiring new template, it would be beneficial to try it first to see if it matches your needs. Now it is a 3 step process:

• install the template package
• instantiate the template
• uninstall the template package

Justification

• even better experience for CLI users
  • easy option to "try it out" before installing the package
  • avoid running outdated templates - always use latest from the source
• popular tools like npx has this experience

[vlada-shubina]

@satyajit-behera is your question about Visual Studio? do you want the templates to be installable in Visual Studio?

Thank you.

[satyajit-behera]

Thanks for the reply. Not really in visual studio. dotnet new works for installed templates. If the templates are directly installed from nuget packages or a folder available in local machine with the same command, it may help a lot in custom template scenarios and multiple version handling.

[vlada-shubina]

@satyajit-behera

do you mean something like this? > dotnet new my-template --from MyNuGetPack::1.0.0 - runs my-template available in MyNuGetPack nuget.org package (version 1.0.0) > dotnet new my-template --from MyFolder - runs my-template from local folder MyFolder

[satyajit-behera]

Yes. Thanks.

[baronfel]

This would be really useful for enabling npx-style usage of templates. Project templates especially you often want to use the latest version on each invocation, and a fire-and-forget experience to run the template without having to do the initial install step can really lower the friction to get started. It also addresses the maintenance aspect of community templates - in the current method you have to update template packages before each invocation if you want to make sure you have the latest. npx-style invocation would (effectively) do an install, invoke, cleanup process to ensure that you always have the latest versions.

[vlada-shubina]

another idea, originally raised in https://github.com/dotnet/templating/issues/1680, is to acquire the template on first-time run from known sources (NuGet feeds from nuget.config) if not yet available. Private feeds might be supported using --add-source option.

The challenge is on how to find the template package containing certain template by short name. For NuGet.org, this is already solved as we have search cache containing this information. But this is not available for private feeds. Possible solutions:

• specify package name for this scenario, then the package will be attempted to be installed prior instantiating
• create a way to index private feeds for available templates at user's machine. The index may be updated once in a while.

[joj]

I really like this idea. It would make shipping some templates out of band easier, and also easier for people to be on the latest without having to wait for our (Visual Studio) release cycles. npx does have a very good convention for this (essentially, "install and run the thing named this"). I'm not sure if that would play nicely with the difference in template naming and nuget naming conventions in .net and nuget, but we could find some sort of metadata for the nupkg that specifies that templates are there and can be used that way.

[baronfel]

but we could find some sort of metadata for the nupkg that specifies that templates are there and can be used that way

We already have PackageType metadata to find templates, and the template metadata itself is in a known location inside such packages - this logic is already what drives the template package indexing that powers dotnet new search. So we should have no blockers.