I'm updating some older PowerShell functions with comment-based help and noticed that Get-Help -Full does not always show all the command metadata. With a normal help block, the synopsis, description, parameter text, and example appear, but fields such as parameter aliases, parameter-set names, default values, dynamic status, inputs, outputs, and function aliases may be blank or missing.
For example, this function has a command alias and a parameter alias:
function Test-FunctionHelp {
[CmdletBinding()]
[Alias('tfh')]
param (
[Parameter()]
[Alias('ParameterAlias')]
[string]$TestParameter
)
}
Get-Help Test-FunctionHelp -Full shows the basic help sections, but the metadata fields are empty. If I add an otherwise meaningless tag such as .A anywhere in the help comment, PowerShell instead displays the aliases, parameter-set information, dynamic status, inputs, outputs, and other generated details. The same behavior occurs regardless of where the help block is placed, and changing line endings does not seem to help.
Why does adding an invalid or unknown help keyword cause this difference? Is there a required section or formatting detail missing from my comment-based help, or is this a PowerShell bug?
2 Answers
The extra tag is not actually fixing the help block. It makes the comment-based help invalid, so Get-Help falls back to generating help directly from the command metadata. That generated output includes details such as aliases, parameter-set names, and dynamic status.
With valid comment-based help, PowerShell has a longstanding limitation or bug where some of those automatically generated fields are omitted. There is no missing help keyword you need to add to make those fields appear. If you want them reliably documented, you can describe them manually in the appropriate help sections, or tolerate the odd fallback behavior.
The position of the help block and the line-ending format are unlikely to be the cause here. A help block can generally be placed according to PowerShell’s comment-based help rules, but changing its location will not resolve this particular metadata issue. The important distinction is whether PowerShell accepts the block as valid comment-based help or falls back to its automatically generated command information.
I tested the help block with both Windows and Unix line endings and still saw the same difference. The documented synopsis, description, and example work either way; it’s the generated metadata that changes when the invalid tag is added.
That explains it. I may still document the aliases explicitly, but it’s useful to know the extra tag is forcing a fallback rather than correcting the help parser.