I love dynamic parameters, but I generally try everything within my power to not use them for anything that I release to other people. I would personally try extra, extra hard if I needed to create a second level dynamic parameter. That being said, I took your problem here as a fun little exercise to see if I could come up with anything (I really do love dynamic parameters). I came up with this (for real, please don’t use this in a production level tool):
That will create a dumb little function named Test-DynamicParamCreation that lets you pass strings to the -OtherDynamicParameterName parameter (which is itself a dynamic parameter), and it will create any number of other dynamic parameters based off of that. Here’s what it looks like in action (it just returns the bound parameter dictionary):
# Example: Test-DynamicParamCreation -OtherDynamicParamName dynparam1, dynparam2 -dyn
PS C:\> Test-DynamicParamCreation -OtherDynamicParamName dynparam1, dynparam2 -dynparam2 value
Key Value
--- -----
OtherDynamicParamName {dynparam1, dynparam2}
dynparam2 value
While I think it’s neat, I have to repeat that I wouldn’t personally use this for anything other than playing around. That’s because it’s violating the PowerShell engine’s contract, since it’s peeking into private member data. The way the binder stuff works could change at any given time, then your command wouldn’t work as expected (depending on how you’re trying to use the data, it might not work at all). I guess I should mention this was only tested in PS 5.1, so I have no idea how far back it will work, and whether or not it will work in PS 6.
It works by getting access to the command’s ‘CmdletParameterBinderController’ instance, which, when DynamicParam is being invoked, hasn’t actually bound any of the parameters. That’s why everything’s in the ‘UnboundArguments’ property. Next, each of those (private) arguments are walked through to try to figure out if the user provided named or unnamed parameters. The code that does that hasn’t been tested very well, but it should work for switches, too. You could rewrite it to know what parameters to expect, and it would probably do even better (you’re on your own when trying to figure out partial parameter names).
Give it a shot and let me know what you think.
By the way, have you looked into argument completers? Normally when people want to know the value of a dynamic parameter during runtime, they’re looking for argument completion. I don’t really know what you’re trying to do with your command, so I’m not sure if that would work for you or not (the way the problem is described, that wouldn’t work, but I figured I’d mention it).