Usability of 'dotnet new'

@matkoch commented on Sun Jan 27 2019

The usage experience with dotnet new is honestly a bit painful when working locally with custom templates. Specifically, I would like to ask for:

• having the opportunity to uninstall templates by short name (I think that’s unique)
• being able to see a version in the list of installed templates
• getting a clear notification, whether a template was installed or uninstalled, instead of printing all available templates

[maartenba]

One example I encountered today:

1. Install any new template
2. Run dotnet new -u and get back a list of installed templates, including Microsoft.Azure.WebJobs.ProjectTemplates!
3. Run dotnet new -u Microsoft.Azure.WebJobs.ProjectTemplates, get back Could not find something to uninstall called 'Microsoft.Azure.WebJobs.ProjectTemplates'.
4. Try it with the name, e.g. dotnet new -u AzureFunctions, same error.
5. Try it with the short name, e.g. dotnet new -u func, same error.
6. Browse through %APPDATA, find the template, remove it. Uninstall worked!

So wholly agree with @livarcocc here, uninstall is a bit of a pain.

[mlorbetske]

Hi @matkoch

For the first item, short name or name are intentionally not unique, they are used as a beginning disambiguator for which set of content to use. Consider the short name console - there’s a template for the 1.0/1.1 targeting flavor of console, 2.0, 2.1, 2.2 and 3.0, each is a different template in a different package, multiple can be installed at the same time and they collapse into a single display template (as determined by groupId) and are addressable by the short name of at least one of the individual templates. Each one of these comes in a separate package (console happens to ship in the same package as class library), and install happens at the package (or directory) level, not on a template by template basis. These things combine to make something like dotnet new -u console very ambiguous - should it remove just the default console or everything that exists in any group addressable by the name console? Should it remove the package that delivered it (which would remove class library as well) or just that template? If you update the package, should it somehow prevent console from coming back or allow it? What’s the process for getting sub-package/directory content back once uninstalled?

For the second, version in terms of individual templates is also one of those things that seems like a straightforward proposition but really is not. Version may not apply at all (at least not in a meaningful way) to templates if installed from a disk location, network share, or (eventually) a git repo. Even in the installation via package case, multiple packages at multiple versions can contribute to the same “display template”, displaying all that information could be quite verbose & we often get complaints about the list mode overrunning the console buffer already. That’s not to say that the current design for the list view must be adhered to, but if it’s not wide like it is now, it’ll likely need to convert to being long & more entries in a long list make the list less useful. There’s a possibility of listing all the contributing templates’ source/version (if applicable) information in detailed help for an individual template - similar to how we present provenance information in the new Web Application project dialog.

For the third, I wholeheartedly agree. having better visibility in to what happened during installation is something that should be improved. We should indicate whether we’ve switched to “component scan” mode (which often trips people up - packages containing DLLs get scanned for extensions to the engine rather than for templates), we should list the installed templates after the fact, we should display the set of template.json files (or, given that alternate engines can be used behind the engine, whatever the marker is for being considered a template candidate). We should provide hints about how to use the trace switches if something does go wrong.

One of the “all up” experience improvements we’ve been considering is to offer a site that can be launched from the command line that gives a more graphical view in to things. For example, finding packages available for installation would be visible there, the template list, their provenance (source, author, version if applicable, etc.) and possibly an experience for instantiating the templates or generating the scripts to do so. With a more rich view, it’s much easier to expose things like this - maybe even along with options to suppress individual templates, set preferences (default language being a relatively common ask), etc.

If the first two items are addressed either by the explanation or the direction we’re thinking, I’d like to close this issue and concentrate on the third, tracking it in a separate issue to allow any thread attached to the issue to be focused on a single topic. Please let us know what your thoughts are.