Considerations for revisiting parameters

[DamianEdwards]

Parameters have a bunch of usability and ergonomics issues today that we should consider when we revisit them:

• Parameters are currently hidden in the dashboard by default. Since 9.4 you can view hidden resources which shows parameters but they have a state of "Unknown" and their values aren't shown in the dashboard resource details.
• No nice APIs for adding a generated password parameter to the model. Instead one needs to discovery and call ParameterResourceBuilderExtensions.CreateDefaultPasswordParameter then pass the result into builder.AddResource which results in the parameter not being hidden. We should likely have an overload of builder.AddParameter or something like builder.AddPasswordParameter
• It's too easy to access the value of parameter resources from code thanks to the Value property in ways which aren't compatible with publishing, and there's nothing that warns you. We should consider making the Value property throw when in publish mode, or even getting rid of the property and forcing other call sites to support accepting the parameters in a first-class way, etc.
• No way to specify the type of value expected in a parameter or validate the value. We have cases where we validate non-parameter values in run mode and throw if they're invalid, but if you get the value via a parameter the value isn't validated at all. We should consider adding support for known parameter data types, e.g. integer, URI, connection string, etc., and that preserve in the model during publish. Or even just being able to specify a description for a parameter so that it can be included in the manifest, etc.

[afscrome]

The first point I think should be addressed by #10094.

[maddymontaquila]

Adding on a few things here too -

• We should seriously consider supporting .env for the polyglot perspective. It feels clunky to have to add a secret store if I already have an existing .env file. For greenfield im happy to prefer/default to secrets, but would love to be able to read (and save to) .env files for a brownfield scenario (plus coding agents all use .env .... lol)
• We need to review why we have both AddParameter and AddParameterFromConfiguration and if having them both distinctly is necessary vs creating an overload for AddParameter that allows you to specify the key
• Something something user secrets single file that @DamianEdwards will have to figure out for .NET 10!

[davidfowl]

The .env file needs more end to end thinking and is related to #10150.

We need to review why we have both AddParameter and AddParameterFromConfiguration and if having them both distinctly is necessary vs creating an overload for AddParameter that allows you to specify the key

Because the arguments are all strings and there's already an overload of AddParameter that takes the same argument types.

[maddymontaquila]

I'm also gonna add that showing all the parameters in the dashboard is super noisy. Would be awesome to have them under a top level resource as children or something. Like I have literalaly one project in this app -

[davidfowl]

LOL, this is what @eerhardt was afraid of. We can consider a few things here now that we have a cleaner hide/show hidden resources. Why shouldn't they show up though 😄

[Was85]

It would be helpful to start with a URL like this: https://localhost:13377/?hiddenTypes=Parameter. Additionally, ensure that the Resource type filter in the top right corner is unchecked. Currently, it is difficult to find the main services, even when utilizing WithParentRelationship. Speaking of WithParentRelationships, it might be better if the default setting were to display them as Collapsed.