Repository navigation
ValueFromPipelineByPropertyName doesn't work with multiple paramsets. #12619
Description
Steps to reproduce
I have defined a cmdlet with two parametersets. Each paramset allows parameters to be passed from the pipeline by the propertyName. The cmdlet works fine if I pass the parameters directly. If I pipeline an object, Cmdlet always resolves the parameter set to Default instead of TestParamSet
CmdLet Code:
[Cmdlet("Get", "SampleCmdlet", DefaultParameterSetName = "Default")]
[OutputType(typeof(string))]
public class GetSampleCmdlet : PSCmdlet
{
[Parameter(Mandatory = true, ValueFromPipelineByPropertyName = true, ParameterSetName = "Default")]
[Parameter(Mandatory = true, ValueFromPipelineByPropertyName = true, ParameterSetName = "TestParamSet")]
public string ParamOne { get; set; }
[Parameter(Mandatory = true, ValueFromPipelineByPropertyName = true, ParameterSetName = "TestParamSet")]
public string ParamTwo { get; set; }
protected override void ProcessRecord()
{
Console.Out.WriteLine($"ParamSet: {ParameterSetName}");
Console.Out.WriteLine($"ParamOne: {ParamOne} ParamTwo: {ParamTwo}");
WriteObject("Hello World!");
}
}
Invoking the Cmdlet with parameters:
PS /Users/> Get-SampleCmdlet -ParamOne "One"
ParamSet: Default
ParamOne: One ParamTwo:
Hello World!
PS /Users/> Get-SampleCmdlet -ParamOne "one" -ParamTwo "two"
ParamSet: TestParamSet
ParamOne: one ParamTwo: two
Hello World!
PS /Users/> skumbham-mac:~ skumbham$ pwsh
Passing the Parameters through the pipeline. Powershell always resolves the parameterset to Default
$test=@{}
$test["ParamOne"]="pipeline-one"
$test["ParamTwo"]="pipeline-two"
$obj = [pscustomobject]$test
$obj | Get-SampleCmdlet
ParamSet: $Default
ParamOne: pipeline-one ParamTwo:
Hello World!
Expected behavior
ParameterSet should be TestParamSet
Actual behavior
ParameterSet defaults to Default paramset.
Environment data
PSVersionTable
Name Value
---- -----
PSVersion 6.2.4
PSEdition Core
GitCommitId 6.2.4
OS Darwin 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Reacted by bb010g
Activity
iSazonov commentedon May 11, 2020
/cc Michael Klement (@mklement0) Maybe dup?
alx9r commentedon May 12, 2020
Here is a repro in PowerShell:
Output:
alx9r commentedon May 12, 2020
Removing
DefaultParameterSetName = "Default"results inChanging the call site to
results in
It's not obvious to me that affinity to the
Defaultparameter set in the OP should be considered wrong. It seems reasonable to me that, when there are two viable parameter sets, the binder would choose the default parameter set.kumbham commentedon May 12, 2020
alx9r thanks for your response. It seems like if we remove the DefaultParameterSetName, normal cmdlet invocation seems to be breaking. here's the output after removing
DefaultParameterSetNamePipelining the object works fine though:
Any other suggestions on how to fix this? alx9r Ilya (@iSazonov)
jhoneill commentedon May 12, 2020
Here's my suggestion
Then we get
and with one field but not the second
No input
Optional param piped but mandatory missing
Optional piped mandatory on the command line
alx9r commentedon May 12, 2020
Srikanth Reddy (@kumbham)
Because each parameter has the
Mandatoryattribute, the parameter binder considers there to be no viable parameter set.I think using another unused parameter set name like
NoneforDefaultParameterSetNamemight achieve the behavior you are expecting:The matter of creating a parameter set with no mandatory parameters at all was puzzling enough to me that it led to stackoverflow#43701900.
Note that this part of the parameter binder is the topic of some recent discussion on #11143 and #11237.