Parameter alias problem in templates installed from file system

I’m developing a new template locally with a parameter symbol I want to specify on the command line. I’ve found that if you add a parameter symbol to the template.json file on disk after installing it with dotnet new -i <PATH> the parameter appears in the output list, but has no aliases.

Steps to reproduce:

• Create this file: ./parameter-issue/.template.config/template.json

{
    "$schema": "http://json.schemastore.org/template",
    "author": "Mark Pim",
    "name": "ParameterAliases",
    "shortName": "paramaliases",
    "sourceName": "ParameterAliases"
  }

• dotnet new -i /path/to/parameter-issue
• Edit the template file:

{
    "$schema": "http://json.schemastore.org/template",
    "author": "Mark Pim",
    "name": "ParameterAliases",
    "shortName": "paramaliases",
    "sourceName": "ParameterAliases",
    "symbols": {
        "foo": {
            "type": "parameter",
            "datatype": "string"
        }
      }  
  }

• dotnet new paramaliases -h

Usage: new [options]
...
ParameterAliases
Author: Mark Pim
Options:

          string - Optional

• (Notice no --foo)
• Now dotnet new -u /path/to/parameter-issue dotnet new -i /path/to/parameter-issue
• dotnet new paramaliases -h

Usage: new [options]
...
ParameterAliases
Author: Mark Pim
Options:
  -f|--foo
            string - Optional

This was surprising behaviour as I’d been previously making changes to the template and source files and rerunning dotnet new without uninstalling and reinstalling the template and it had worked, and I’d expect the tool to either not pick up new parameters in the template, or pick them up completely (with aliases). Is this expected behaviour?

Environment

OS: Windows 10 dotnet --version: 2.1.300

[seancpeters]

Seems reasonable to me, I don’t see any real caveats.

As a workaround, after making changes to the template.json, you can cause the cache to be updated by running: dotnet new --debug:rebuildcache

• Standard Disclaimer: Input flag starting with --debug: are not officially supported, and may be removed or change their behavior at any time. (Not that it’s likely to happen).

If you’re interested in implementing a change for this, I can work with you on the details. The actual cache update can be performed with the existing code that runs when using the --debug:rebuildcache flag, which is found here: https://github.com/dotnet/templating/blob/4bd80f0577550c7f36867b53d0c074f8f3dcde17/src/Microsoft.TemplateEngine.Edge/Settings/SettingsLoader.cs …particularly the method RebuildCacheFromSettingsIfNotCurrent.

For this task, the above method probably wants some minor refactoring, moving the actual cache rebuild code into a new method, e.g.: RebuildCacheFromSettings() which does it unconditionally, and only gets called when appropriate.

The checks for a template.json getting updated and triggering a cache rebuild would need to occur early in the invocation of dotnet new, probably at the same place RebuildCacheFromSettingsIfNotCurrent() is currently called, which is in this file: https://github.com/dotnet/templating/blob/stabilize/src/Microsoft.TemplateEngine.Cli/New3Command.cs …in the method ExecuteAsync()

As @mlorbetske mentioned, to facilitate the automatic checking, the file templatecache.json would need to store the timestamps of the various template.json files. One caveat is that this only makes sense for file-based template installs, not zip / nupkg installs. I can get into more details on that as needed.

[seancpeters]

That sounds about right - but I think if forceRebuild is true, it should always rebuild the cache. That’s how the --debug:rebuildcache option is applied.

You’re correct about the MountPointFactoryId, we’d only have to look at the mount points that are file based. One thing that may not be intuitive is that nupkg’s and zip’s are both handled by the same mount point factory / mount point implementation - since nupkg’s are just zips with a bit of enforced structure in them.

Definitely feel free to make a PR 😃