Query regarding limit on maxmimum number of ParameterSets for powershell cmdlet? RRS feed

  • Question

  • Hi,

    Can anyone please confirm if there is official limit on the maximum number of ParameterSets for a custom cmdlet? For our powershell module, we are facing issue in the cmdlets when the number of ParameterSets exceeds beyond 32. 

    On the basis of this, I have few questions:

    1.) Is 32 the limit of maximum number of parametersets that a cmdlet can have?

    2.) Is there any work around for this issue?

    3.) Is there any plan to increase the number of parameterset in future powershell releases?


    Vinay Ravish

    Wednesday, September 26, 2018 6:26 AM


All replies

  • What is the error you are getting?  What version of PowerShell? Windows?


    Wednesday, September 26, 2018 7:15 AM
  • Hi,

    Thanks for your question.

    As far as I know, PowerShell function has any number of named parameters. There are not limit on the maximum number of ParameterSets. As jrv said, you should post the error.

    Best Regards,


    Just do it.

    Wednesday, September 26, 2018 7:55 AM
  • Hi jrv,

    I am using windows 10.


    powershell version is:


    Major  Minor  Build  Revision
    -----  -----  -----  --------
    5      1      15063  1266


    Issue statement:

    I have a Get cmdlet, which has a default parameterSet named as "All". As per our implementation, any "Get" cmdlet in our module should run without any parameters(because there are no mandatory parameters under "All" ParameterSet). This rule is followed by all our Get cmdlets and cmdlets worked fine. But after the addition of 33rd parameterSet, "Get" cmdlet start asking for mandatory parameter from a parameterSet(just an observation: last parameterset in sequence). So cmdlet execution basically switched from default parameterSet (i.e. "All") to another parameterSet(last parameterset in sequence) and asks the mandatory parameter specified in that particular parameterSet.

    Expected behavior:

    C:\> Get-xxxEquipmentManufacturingDef

     and cmdlet should return objects of of type "EquipmentManufacturingDef". This cmdlet worked fine until the parameterSets were less than 32.

    New Behavior which is causing issue:

    C:\> Get-xxxEquipmentManufacturingDef

    cmdlet Get-xxxEquipmentManufacturingDef at command pipeline position 1
    Supply values for the following parameters:

    As you can see above the cmdlet started asking for mandatory parameter "EquipmentTpmCapProvider" defined in parameterSet named "EquipmentTpmCapProvider".

    Please let me know if you need any more information.


    Vinay Ravish

    Wednesday, September 26, 2018 8:20 AM
  • It looks like you have an error somewhere in your declaration.  There is no indication that means you have too many parameter sets. 


    Wednesday, September 26, 2018 8:34 AM
  • Wednesday, September 26, 2018 8:37 AM
  • Hi Jrv,

    Thanks for the link, i have already seen this. But this link does not talk anything about the workaround for this issue and when Micorsoft will address this issue.

    Could someone please share the information if Microsoft knows about this issue(or any bug which we can track) and is there any plans to fix this issue in any powershell future releases?

    thanks a lot,

    Vinay Ravish

    Wednesday, September 26, 2018 8:55 AM
  • There is no fix and no workaround.  As stated it is a hard limit.

    Post in UserVoice if you want to suggest this get changed.


    Wednesday, September 26, 2018 8:57 AM
  • Thanks for your share about this issue.

    Just do it.

    Wednesday, September 26, 2018 8:58 AM
  • Jrv,

    actually the cmdlet works fine when it has 32 parameterSets and when I add extra parameterSet, it start having the issue. I have checked multiple times in my c# code.

    i am positive that there is no error in my code.


    Vinay Ravish

    Wednesday, September 26, 2018 8:59 AM
  • As I noted above.  32 is the maximum and it cannot be changed.

    You issue is not for this forum.  Post in UserVoice or in the C# forum for further information.


    Wednesday, September 26, 2018 9:30 AM