Possibility to install pre-release templates?

[tidyui]

It would be nice to be able to install pre-release packages as templates like you can with ordinary NuGet-packages. For example

> dotnet new -i MyPackage.Identity -pre

[mlorbetske]

Thanks for the suggestion @tidyui.

TL;DR: unfortunately, this isn't likely to get added soon. Until a supporting feature from NuGet is added, we can't actually do this properly, once it's there though it's technically possible to do. Beyond that, we're looking at ways of making the installation experience better in general - possibly adding more direct coupling between the thing handling the installation request and the command line options that have been specified.

There are a few considerations here:

• There's currently no equivalent option for dotnet restore or dotnet add package (feature request on the NuGet repo) to allow prerelease package versions to be installed implicitly
• The installation directives (when NuGet packages are involved) creates a csproj and calls restore on it, so, given the above issue, the proposed -pre switch would have to influence the patterns for package versions being generated in to that file. *-* is not accepted by NuGet as a valid version, requiring the major.minor.patch to be specified - meaning that at a minimum you'd still need dotnet new -i MyPackage.Identity::{major}.{minor}.{patch} -pre. Given that this is intended to be a short-hand, the command to leverage it actually being longer seems like it defeats the purpose
• Multiple -i switches are allowed and are not positionally linked to any other switches (you'd be able to specify -pre exactly once and it'd apply to all things being installed), which might be OK (it's probably more common to install one package at a time)
• Similar to the --nuget-source option, -pre would apply only to a subset of the things that could be installed, though -pre seems less NuGet specific (ex. if in the future support for installing for a Git repo is added, what does -pre do when used in conjunction with that installation request?). The switch being specific to NuGet installation requests could be documented, but it still feels a bit rough

A while back, we started some refactoring of the installer to allow additional installers to handle -i (getting ready for supporting Git installation). Maybe we need to go a step further with that thinking, something like this maybe

dotnet new -i {provider} [[provider specific named options]]

Using it for NuGet install could look something like

dotnet new -i NuGet --package MyPackage.Identity --version 1.0.0-* --source https://somewhere/

Or, for a file system based one

dotnet new -i Local --source c:\templates\MyTemplates

This would make the logic for deciding how to install something much more straight forward & allow these install mechanism specific options to feel more natural. The only downside is it'd limit to being able to install only one thing at a time, but maybe that's ok. @seancpeters thoughts?

Also, to prepare for the possibility of leveraging the -pre switch from dotnet add package (assuming there's not an equivalent for restore), perhaps we should move to creating an empty csproj and using that command to add the package to it rather than emitting the PackageReference directives specifically. We'd still need to call restore with the output folder set, but this could at least take care of some of the issues in forming up the versions.

[tidyui]

Thanks for your detailed answer! From an "end-users" point of view in this matter, here's my five cents, given that I managed to understand everything you wrote :)

• I would have never guessed that I could install multiple packages at the same time without going through the documentation carefully. Even knowing that I could, I'm not really sure that I would ever use it. For me, normal use is rather finding a new template and then installing it.

• I totally understand the syntax with the provider in it, it makes it semantically clear what your doing and also probably easier to structure the code (passing the following parameters on to the provider called). For a developer installing templates I don't see any downside as I guess most people publishing packages provide people with clear instructions on how to install their template (I know I do anyway).

• The specifics about versioning and what goes on in the background is beyond me knowledge, but the use case for me is being able to install the latest preview version of framework x's templates. It's more like a "stay safe with the latest release" vs "go bleeding edge" choice.

All of this however made me think of another question that I've been thinking about since I have a template published myself on NuGet.

Is there any easy way to just update all installed templates to the latest version, like brew update. Also, is there any way, or plan on how to notify users that there are actually newer versions of their templates available? For the asp.net team at Microsoft this probably comes naturally, I'm guessing that when you download a new version of the .NET CLI it includes new versions of the templates bundled with the rest of the package, but for the rest of us, how do we make sure our users don't sit on old versions of a project template?

Regards

[RobotOptimist]

Just in case anyone needs to know
You can do this by providing the exact version in this format:

dotnet new -i TheTemplateNuget::0.0.1-the-exact-version

I hope this is helpful. Seems the issue can be closed?

[Eilon]

I wonder why was my comment deleted? My comment gave a clear example of why this feature would be useful. It's fine not to do it, but the comment I think was still valuable.

The comment was to this effect:

Having something like a -pre flag is important if you just want "the latest pre-release version of a template" and either don't know or don't care what the exact version is. Without such a flag the user must always know the exact version to install. In non-pre-release cases that isn't the case. Plus, NuGet has this feature for regular packages.