Why does accessing a parameter variable's attr

Thanks to the great people at StackOverflow we received a very good answer on how to retrieve the values defined in ValidateSet within the Param() clause of a script or function:

Param (
    [ValidateSet('Startup', 'Shutdown', 'LogOn', 'LogOff')]
    [String]$Type = 'Startup'
)

(Get-Variable Type).Attributes.ValidValues

The only thing that bothers me is that this code only works the first time when you run it in the PowerShell ISE. The second time you run it, there is no output generated.

Is there a workaround to have it always working? We use PowerShell 4.0 on Win 7 and Win 2012.

回答1:

tl;dr

The observed behavior is arguably a bug as of Windows PowerShell v5.1 / PowerShell Core v6.0-beta.4 - see this GitHub issue.
To bypass the problem without side effects, use the following approach:

Param (
    [ValidateSet('Startup', 'Shutdown', 'LogOn', 'LogOff')]
    [String] $Type = 'Startup'
)

$MyInvocation.MyCommand.Parameters['Type'].Attributes.ValidValues

If there's a chance that Set-StrictMode -version 2 or higher is in effect or you're using PSv2, use

Param (
    [ValidateSet('Startup', 'Shutdown', 'LogOn', 'LogOff')]
    [String] $Type = 'Startup'
)

($MyInvocation.MyCommand.Parameters['Type'].Attributes |
  Where-Object { $_ -is [System.Management.Automation.ValidateSetAttribute] }).ValidValues

Optional background information

The problem is not related to the ISE per se, but to repeated dot-sourcing (the ISE just happens to run all scripts by dot-sourcing them).

Dot-sourcing runs scripts in the current scope (in the caller's scope itself, as opposed to in a child scope) and therefore typically modifies the current scope's state, such as by adding variables.
If you dot-source a script from an interactive session, you're effectively modifying the global session state, which is how definitions from the PS profile files are loaded, for instance.

In the case at hand, a dot-sourced invocation of the script effectively adds parameter variable $Type to the invoking scope as a regular variable, as designed.

The bug surfaces when you dot-source the same script again (assume that the script in the question is present as ./script.ps1:

After the first dot-sourced invocation, variable $Type is still intact with respect to its attribute:

> . ./script.ps1; (Get-Variable Type).Attributes.Count
Startup
Shutdown
LogOn
LogOff
3   # PS implicitly adds 2 add'l attributes behind the scenes

When you dot-source again, the attributes are lost:

> . ./script.ps1; (Get-Variable Type).Attributes.Count
0

回答2:

First of all, this behavior is only seen in PowerShell ISE (it works perfectly outside). This might be explained by the following post.

Reading it, you'll see that there is a workaround:

Param (
    [ValidateSet('Startup', 'Shutdown', 'LogOn', 'LogOff')]
    [String] $Type = 'Startup'
)

(Get-Variable Type).Attributes.ValidValues

# Do your stuff here

Remove-Variable Type