Powershell: Dynamic parameters are not imported as variables

[yecril71pl]

Steps to reproduce

FUNCTION TEST-PARAM { [CMDLETBINDING()] PARAM([SWITCH] $B)
 DYNAMICPARAM {
NEW-OBJECT Management.Automation.RuntimeDefinedParameterDictionary |
 % { $_.ADD('A', (
NEW-OBJECT Management.Automation.RuntimeDefinedParameter (
'A', [SWITCH], ((
NEW-OBJECT  Management.Automation.PARAMETERATTRIBUTE
))
)
)
)
$_
 }
RETURN
 } PROCESS { '[{0}={1} {2}={3}]' -F $A, $PSBOUNDPARAMETERS.A, $B, $PSBOUNDPARAMETERS.B 
 }
 }

TEST-PARAM -A -B

Expected behavior

[True=True True=True]

Actual behavior

[=True True=True]

Environment data

[mklement0]

Perhaps someone (@SeeminglyScience?) can speak to a potential design rationale and whether there are good reasons for this behavior, which can certainly be a pitfall whose avoidance may be non-obvious; just to provide a historical note: dynamic parameters always needed to be accessed via $PSBoundParameter; they were never represented as (what would have to be implicitly defined) local variables.

[vexx32]

@rjmholt might be the other person to poke on that, if anyone still knows what the rationale was there... But yep, this has always been the case as far as I'm aware.

It's one of many reasons I tend to recommend against use of dynamicparam unless there's no other alternative.

[SeeminglyScience]

I don't think it's a design decision necessarily (though I could be wrong), just kinda looks like a pain. Right now dynamic parameters are handled the same way for script commands as they are for binary cmdlets. The dynamic parameter binder is pretty unaware of what the underlying command type is. That could almost definitely be changed, just with a bit more complexity than you'd think.