New-MarkdownHelp doesn't respect SupportsWildcards and PSDefaultValue attributes

[vors]

• we don't respect [SupportsWildcards()] attribute
• we don't respect [PSDefaultValue(Help='bar')]$foo. Is it a thing? How is it different from $foo = 'bar'?

[cormacpayne]

@vors Hey Sergei, one of our partners for Azure PowerShell is running into this issue when updating the help for their cmdlets. They are using the [SupportsWildcards()] attribute on a parameter, but the help is still showing Accept wildcard characters: False in the markdown after they run Update-MarkdownHelpModule. She pointed out that the transformer is looking for SupportsWildCards and not SupportsWildcards, so this may be due to a capitalization issue. Thoughts?

[BernieWhite]

@vors Haven't see this before. My interpretation of the help for PSDefaultValue is that it is designed for reflection when the assigned value might not directly correlate to the default value. Use of the attribute, has no impact on the actual assigned value. Although I am confused with your example above and how that correlates to the attribute help. PSDefaultValue appears with have a Help and a Value property.

Based on this I would propose that we would want a PSDefaultValue to override the default value assigned to the parameter. But should this be on Help or Value I'm unclear. Thoughts or example use cases?

Not sure how frequently it's used in function based help. Makes more sense for .NET cmdlet implementations.

[vors]

@cormacpayne sorry, slipped out of my attention.
Capitalization usually doesn't matter, but it's a good point, thank you for the investigation.

I'm not super convinced about the default value, because in lots of help files I seen it's used pretty arbitrary in maml. You may want to have a text description, instead of a PSDefaultValue.ToString().

The SupportsWildcards is more straightforward: we should just find out why it's not updated from reflection and fix it.

Current workaround is to specify this value in the maml as well (yeah, duplicated work)

[BernieWhite]

So the reason SupportsWildcards does not update is because we don't reflect the value from the command, we rely on the help being the source of truth, but the PowerShell engine doesn't auto-generate this property so it would never be correct unless you already had a MAML document that declared it.

[BernieWhite]

Also noted that we don't represent ValidateRange.

[BernieWhite]

@vors I think this document more closely describes the intent of PSDefaultValue. https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_functions?view=powershell-6#named-parameters

[blueww]

When can we get the issue fixed?
We have a customer reported issue related with this: Azure/azure-powershell#7848

The parameter -Blob has "Accept wildcard characters" as false in help: https://docs.microsoft.com/en-us/powershell/module/azure.storage/get-azurestorageblob?view=azurermps-6.12.0
But actually it supports wildcard, and we have add the [SupportsWildcards()] tag to support it in code. See:
https://github.com/Azure/azure-powershell/blob/622034f1177072edfc78aab53886e81d808d91ba/src/Storage/Commands.Storage/Blob/Cmdlet/GetAzureStorageBlob.cs#L44
But even I manually set it to true in help file, when regenerate help file, the value will be set to false automatically.