dotnet
[Epic] Provide mechanism for using defaultName instead of Currentfolder name as fallback if --name is not specified
See the following issues for more details:
This impacts https://github.com/dotnet/aspnetcore/issues/11824 and associated PR https://github.com/dotnet/aspnetcore/issues/11824
The relevant areas of templating code are: https://github.com/dotnet/templating/blob/f15388ee6e45a8923fba0f54f55154aee991fb84/src/Microsoft.TemplateEngine.Cli/TemplateInvoker.cs#L153
https://github.com/dotnet/templating/blob/f15388ee6e45a8923fba0f54f55154aee991fb84/src/Microsoft.TemplateEngine.Edge/Template/TemplateCreator.cs#L71
Note that fixing this for the CLI should not regress VS scenarios, but we should be pretty well insulated against that since the IDE passes the actual name as the fallback, and all IDEs always explicitly pass the name: https://github.com/dotnet/templating/blob/f15388ee6e45a8923fba0f54f55154aee991fb84/src/Microsoft.TemplateEngine.IDE/Bootstrapper.cs#L93
Investigate whether if we can auto-increment default name, if it ends with digit and the file with default name already exist.
For what its worth, in the Visual Studio host we strip off any trailing digits on the default name before passing it to the IDE for use in the New project dialog, since the new project dialog requires for there not to be trailing digits to increment property - it assumes that any trailing digits are "fixed".
@phenning we discussed the following approach for default name:
- we would still use the name of the current folder as default option
- we would introduce another property to template.json configuration, similar to
preferDefaultName: in case set to true default name will be used instead of the current folder.
As we understand the use case of https://github.com/dotnet/aspnetcore/issues/11824 it's more applicable to item templates, and default name would be something similar to Class1. User might want to use dotnet new to create multiple items, and then second attempt may fail due to file(s) already exist. Auto-increment might be useful to avoid this failure, moreover it would be similar to VS behavior, however on the other hand probably the user will pick up non-default name for these items.
For now it's just an idea, if it's too complicated we might drop it.
Agreed not to implement auto-increment of default name as part of current issue.
defaultName will be enabled to be used if preferDefaultName is set to true. In case preferDefaultName is false or missing current directory name will be used.
Just came across with this issue. Considering that defaultName automatically enriches the Project Name input when creating a project from Visual Studio UI, I would expect a similar behavior in the CLI.
It would be nice to have this implemented, as currently users are forced to use --name | -n.
