Sometimes, as Don Jones alludes to in this thread, Powershell gets a little too clever in its attempts to "coerce" variables. In this case, it's the battle between ValueFromPipelineByPropertyName and ValueFromPipeline on a (string?) parameter.

I think the quick upshot is that, if you want what's promised by ValueFromPipelineByPropertyName, you need to roll it on your own.

See this, from said Don Jones:

Another option is to add an -InputObject parameter that accepts, ByValue, the exact object type being output by your first cmdlet. That way, it should bind without coercion. You'd KNOW you were getting that whole object, so you could grab the appropriate property internally. Make that part of a separate parameter set so that folks can do one or the other, but not both.

This is essentially how a lot of built-in cmdlets, like Stop-Service and Stop-Process, work.

Interesting discussion at that thread over whether the coercion is a bug (apparently not) and if that intended behavior is a good idea (not necessarily).

Labels: