PowerShell 错误？ 无法通过管道将 ComputerName 属性传递给 Get-Service（混合 byvalue 和 bypropertyname）

Question

Seems like a bug, no? In this case, PowerShell converts the hashtable to a string '@{computername=comp001}' and tries to use it with -Name (ByValue) instead of -ComputerName (ByPropertyName). Even PS 6 does it. Piping to Get-Service -Name * works fine.

PS C:\> [pscustomobject]@{computername='comp001'} | get-service
get-service : Cannot find any service with service name '@{computername=comp001}'.
At line:1 char:45
+ [pscustomobject]@{computername='comp001'} | get-service
+                                             ~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (@{computername=comp001}:String) 
[Get-Service], ServiceCommandException
    + FullyQualifiedErrorId : 
NoServiceFoundForGivenName,Microsoft.PowerShell.Commands.GetServiceCommand

Answer 1

Seems like a bug, no?

Not a bug as such, but an unexpected consequence of the parameter design of the Get-Service cmdlet:

Attaching the ValueFromPipeline attribute to a parameter typed [string] / [string[]] or [object] / [object[]] (or [psobject] / [psobject[]] ) makes that parameter bind to any pipeline input , possibly in addition to binding to other parameters - unless that parameter is bound by command-line argument , which is what your -Name * workaround does.

• The reason is that instances of any data type can be converted to [string] / are derived from [object] ( [psobject] ), causing any input object, irrespective of type, to bind to that parameter.

In short: the problem here isn't that [pscustomobject]@{computername='comp001'} isn't bound to -ComputerName - it actually is - it is that it is also bound to -Name , invariably.
The PowerShell parameter binder fundamentally binds pipeline input to all suitable parameters , not just one.

As stated, the only way to prevent the -Name binding from the pipeline is to pass a value by argument - even if that value is just * to signal inclusion of services of any name.

The behavior is now also being discussed on GitHub .

---

Side note:

As js2010 (the OP) points out, it is possible to meaningfully combine the ValueFromPipeline and ValueFromPipelineByPropertyName attributes in a single parameter , the way Get-Service does, but note the constraints:

• It only works for a parameter not typed [object] or [psobject] / [object[]] or [psobject[]] (such a parameter would invariably bind everything by value without ever considering properties ).

  • If the type is [string] or [string[]] , properties are considered, but you cannot have additional pipeline-binding parameters , because that presents the original problem: the [string] / [string[]] parameter will invariably also bind.

• The type of an input object's property matching the parameter name must either match the parameter type or must at least be convertible to it in order to be bound.

Here's a sample command that binds the same service to -Name first as a string and then as an object with a .Name property:
'rpcss', [pscustomobject] @{ Name = 'rpcss' } | Get-Service

Answer 2

As you are sending a complete object to Get-Service , it has only two options for binding: Name and InputObject , which are the parameters that accept ByValue pipeline input. Unfortunately, your object is not in a form that either understands.

You can see what PowerShell is doing by running this Trace-Command :

Trace-Command -Name ParameterBinding -PSHost -Expression {[pscustomobject]@{ComputerName='comp001'} | Get-Service}

As you say, the way around this is to supply a value for -Name , so it doesn't attempt to bind it:

[pscustomobject]@{ComputerName='comp001'} | Get-Service -Name *

Once again, you can use Trace-Command as above to see that it is now happy to bind '*' to -Name , then it goes on to bind the additional parameters like -ComputerName .

The PowerShell documentation ( about_Parameters ) states:

When a parameter is "True (by Value)", Windows PowerShell tries to associate any piped values with that parameter before it tries other methods to interpret the command.