Missing new parameters '--kestrelHttpsPort' and '--kestrelHttpPort'

[Tiberriver256]

These two parameters were added to quite a few templates in this PR and seem to be missing from the documentation here.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 267c314a-e630-097f-edc6-d417be6db191
• Version Independent ID: af236ebe-5a79-fb2b-42a0-e5720ee732ae
• Content: .NET default templates for dotnet new - .NET CLI
• Content Source: docs/core/tools/dotnet-new-sdk-templates.md
• Product: dotnet-fundamentals
• Technology: dotnet-cli
• GitHub Login: @tdykstra
• Microsoft Alias: tdykstra

[tdykstra]

@vlada-shubina Looks to me like these new parameters are hidden and shouldn't go in this article, can you verify?

[vlada-shubina]

@captainsafia @mkArtakMSFT could you please check above?

[captainsafia]

The flag is marked as hidden, however, it looks like I'm still able to invoke it when using the CLI command, e.g. the following command will update the launchSettings.

$ dotnet new web --kestrelHttpsPort=5003

My assumption would be that the isHidden flag prevents the argument from being used but since it looks like it is available it might be worthwhile to document.

[vlada-shubina]

@captainsafia

isHidden just prevents parameter from being shown in help, and probably in Visual Studio (@phenning ?) - it is still a parameter, and if specified by user in CLI it will be used.
In case you don't want the user to be able to change this value (i.e. this is not a parameter), you may use constant symbol instead: https://github.com/dotnet/templating/wiki/Available-Symbols-Generators#constant

[phenning]

AFAIK Visual Studio won't even get these parameters when we enumerate the parameters on the ITemplateInfo. Looking at https://github.com/dotnet/templating/blob/main/src/Microsoft.TemplateEngine.Abstractions/ITemplateParameter.cs it seems like this would be prefiltered from the hosts?

[captainsafia]

isHidden just prevents parameter from being shown in help, and probably in Visual Studio (@phenning ?) - it is still a parameter, and if specified by user in CLI it will be used.

In that case, I would say we should document these two. They are practical for users who want to maintain the old behavior of keeping hard-coded port values instead of getting randomly assigned available ones.