Param in CmdletBinding not mandatory and error/misspelled checking - powershell

Hey all I have a powershell script that I need to send some parameters to. However, sometimes I do not need to send any or maybe one out of the two.
[CmdletBinding()]
param (
[Parameter(ParameterSetName='SkipAutoLoader')][switch]$SkipAutoLoader,
[Parameter(ParameterSetName='AppPool')][switch]$AppPool
)
[more code here....]
if (-not $SkipAutoLoader) {
$services += "Auto Loader Service"
}
[more code here....]
The above works just fine as long as I have either:
.\Start-AkkServides.ps1 -SkipAutoLoader
or
.\Start-AllServices -AppPool
If I have both together:
.\Start-AllServices -SkipAutoLoader -AppPool
It errors out.
C:\src\Start-AllServices.ps1 : Parameter set cannot be resolved using the specified named parameters.
At line:1 char:1
+ .\Start-AllServices.ps1 -SkipAutoLoader -AppPool
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Start-AllServices.ps1], ParameterBindingException
+ FullyQualifiedErrorId : AmbiguousParameterSet,Start-AllServices.ps1
I also want to be able to determine if the param has the valid -SkipAutoLoader and/or -AppPool but with something else tagged like -SkipAutoLoader43
I would like to say that -SkipAutoLoaderbob is an invalid param. But do not show an error if either param is not present.
Loads Fine:
.\Start-AllServides.ps1 -SkipAutoLoader
Loads Fine:
.\Start-AllServides.ps1 -AppPool
Does Not Load Fine/causes error:
.\Start-AllServides.ps1 -SkipAutoLoader -AppPool
Does Not Load Fine/casues error:
.\Start-AllServides.ps1
Does not say param is not valid:
.\Start-AllServides.ps1 -SkipAutoLoaderbob
Does not say param is not valid:
.\Start-AllServides.ps1 -AppPool7
Possible to do with powershell?

Your parameters are in separate parameter sets (only[1]), so by design they cannot be used together.
If your parameters can be freely combined, you don't need to define parameter sets at all.
Since your script is an advanced one, thanks to [CmdletBinding()] and/or [Parameter()] attributes, calling with non-declared parameter names is automatically prevented.
However, the lack of a default parameter-set designation in the [CmdletBinding()] attribute causes a more fundamental error if you only specify an unsupported parameter name (such as -SkipAutoLoaderbob): PowerShell then doesn't know which of the two defined parameter sets to select, because no declared parameter can be bound (before even considering whether the parameter name given is valid, perhaps surprisingly)
Use [CmdletBinding(DefaultParameterSetName='AppPool')], for instance, to designate the default parameter set.
Assuming that your two parameters can be freely combined and neither is mandatory (which [switch] parameters shouldn't be anyway), your code can be simplified to:
[CmdletBinding()]
param (
[switch] $SkipAutoLoader,
[switch] $AppPool
)
# Output the name of the active parameter set.
$PSCmdlet.ParameterSetName
Note that non-mandatory parameters without explicit parameter-set membership (and other non-default parameter properties) do not require [Parameter()] attributes.
When you invoke the script, you'll see that PowerShell implicitly defines a parameter set in the absence of explicitly declared ones, named __AllParameterSets.
[1] Note that a parameter can belong to multiple explicitly specified parameter sets, via multiple [Parameter(ParameterSetName= '...')] attributes. Any parameter without an explicit parameter-set membership is implicitly part of all parameter sets.

Related

Parameter set cannot be resolved with mutually exclusive non default parameters

Following is full param block signature, I tried almost every possible solution that I'm aware of such as
adding Mandatory to File and Thumbprint parameters sets, removing default parameter set etc, none of which works.
Problem description and desired functionality is this:
Domain parameter is always required while File and ThumbPrint are optional but mutually exclusive.
I run this test as follows:
.\Set-WinRM* -Domain VM-PRO
Parameter set cannot be resolved using the specified named parameters.
function Set-WinRM
{
[CmdletBinding(PositionalBinding = $false, DefaultParameterSetName = "None")]
param (
[Parameter()]
[ValidateSet("HTTP", "HTTPS", "Any")]
[string] $Protocol = "HTTPS",
[Parameter(Mandatory = $true)]
[Alias("ComputerName", "CN")]
[string] $Domain,
[Parameter(ParameterSetName = "File")]
[string] $CertFile,
[Parameter(ParameterSetName = "ThumbPrint")]
[string] $CertThumbPrint,
[Parameter()]
[switch] $SkipTestConnection,
[Parameter()]
[switch] $ShowConfig
)
}
EDIT:
I never use dynamic parameters, if this can't be done normally maybe you can provide an example on how to define them in this example, that would be great.
I copy and pasted your code into Powershell ISE, and added echo $domain to the end to test the parameter. It returns the value normally, without errors:
I don't see any issues with your parameter block, which leads me to believe something else is at fault. If you type out .\Set-WinRM.ps1 -Do, or Set-WinRM -Do can you tab-complete it successfully? If you run Set-WinRM without parameters at all, does it prompt you for Domain:?
I would only expect to see that error if you had additional parameter sets with $domain doing different things, or maybe if a module you have loaded has the Set-WinRM command and it's taking precedence. Try Get-Command Set-WinRM and make sure the CommandType is Function and the Source is blank.

Trying to use parameters dynamically using powershell

I am trying to setup dynamic parameters that vary depending on if you are adding or modifying/removing a drone. Ex: If you are adding a drone you would need its IP/Name/Location.. To remove the drone you would only need its name. I have tried looking online and try various examples I've seen but I am completely stuck here. Any help to steer me in the right direction would be appreciated. I am somewhat new to powershell. Here's what I have.
[CmdletBinding(SupportsShouldProcess=$True)]
Param( [Parameter(Mandatory=$true,
HelpMessage = "Add remove or Modify a drone?")]
[ValidateSet("Add", "Remove", "Modify")]
[String]$Action)
DynamicParam{
if ($action = "Add"){
Param( [Parameter(Mandatory)]
[ValidateSet("NorthAmerica", "SouthAmerica", "NorthernEurope","UK", "CEE", "FRMALU", "SouthernEurope", "AsiaPacific")]
[String]$curRegion,
[Parameter(Mandatory)]
[IPAddress]$ip,
[Parameter(Mandatory)]
[String]$droneName)
}
if ($action = "Remove"){
Param(
[Parameter(Mandatory)]
[string]$droneRemoveName)
}
}
Consider driving your parameter constraints with named Parameter Sets instead. I'm suggesting this because dynamic parameters don't work quite like you think they do, but named parameter sets are an easier way to solve your problem. In case you're interested, here's a blog post explaining how to use dynamic parameters and it winds up being pretty manual parameter handling.
You can add a parameter to more than one parameter set depending on the contexts in which each parameter is required. Instead of using -Action ACTION as a driver for a dynamic parameter, use a [switch] instead, such as -Add and -Remove, and have each switch part of its own parameter set. For example, when defining your parameters, it may look something like this:
Param(
[Parameter(ParameterSetName='Remove')]
[switch]$Remove,
[Parameter(ParameterSetName='Add')]
[switch]$Add,
[Parameter(ParameterSetName='Remove', Mandatory)]
[Parameter(ParameterSetName='Add', Mandatory)]
[string]$IPAddress
)
In this example, -IPAddress is valid when you use the -Add or -Remove switch, but won't be relavant outside of this context. Of course, if a parameter should only be valid for a certain parameter set, don't define it under more than one parameter set name.
If you want to make sure at least one "action" switch is defined before executing, you can check that one of those parameters was used when invoking the cmdlet by checking $PSBoundParameters:
('Add' -in $PSBoundParameters.Keys) -Or ('Remove' -in $PSBoundParameters.Keys)

Questions/Problems related to set-winuserlanguagelist command

I'm building a code to fix keyboard layout situation on windows 10. With automated solution, I decided to use powershell. But the problem is that I'm pretty new in it and face certain problems. I managed to dig a script to change keyboard layouts, however it changes only to one language. As I try to create array with 2 languages:
$langlist=$lang_en,$lang_ru
set-winuserlanguagelist $langlist
It simply returns me next error:
Set-WinUserLanguageList : Cannot convert 'Microsoft.InternationalSettings.Commands.WinUserLanguage' to the type
'Microsoft.InternationalSettings.Commands.WinUserLanguage' required by parameter 'LanguageList'. Specified method is
not supported.
At line:1 char:25
+ set-winuserlanguagelist $langlist
+ ~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Set-WinUserLanguageList], ParameterBindingException
+ FullyQualifiedErrorId : CannotConvertArgument,Microsoft.InternationalSettings.Commands.SetWinUserLanguageListCommand
When I tried to use next command: $test = Get-WinUserLanguageList, the command works well with set-winuserlanguagelist.
The full script:
$keys='0809:00020409', '0419:00000419'
$lang_en=new-winuserlanguagelist en-gb
$lang_en[0].inputmethodtips.clear()
$lang_en[0].inputmethodtips.add($keys[0])
$lang_ru=new-winuserlanguagelist ru
$lang_ru[0].inputmethodtips.clear()
$lang_ru[0].inputmethodtips.add($keys[1])
$langlist=$lang_en,$lang_ru
set-winuserlanguagelist $langlist
Please check the following commented code snippets:
PS D:\PShell> ### Type mismatch
$langlist=$lang_en,$lang_ru
### Note the difference in type:
$langlist.gettype().Name ### Object[]
(Get-WinUserLanguageList).gettype().Name ### List`1
Object[]
List`1
PS D:\PShell> ### Use the following:
$langlist = Get-WinUserLanguageList
$langlist.Clear()
$langlist.Add($lang_en[0])
$langlist.Add($lang_ru[0])
$langlist.gettype().Name ### List`1
List`1
PS D:\PShell> <### The next cmdlet should work now:
set-winuserlanguagelist $langlist
<##>
The problem is that you're using New-WinUserLanguageList twice, with each call returning a list, so that $langlist = $lang_en, $lang_ru mistakenly created an array of (single-item) lists rather than a single list with two items, which caused the (nonsensically-sounding) type-mismatch error you saw.
Very awkwardly, however, cmdlet New-WinUserLanguageList only allows you to specify one language, even though it returns a list type ([Collections.Generic.List[Microsoft.InternationalSettings.Commands.WinUserLanguage]]).
That is, the following should work, but doesn't:
# Try to create the list with *2* entries
$langlist = New-WinUserLanguageList en-gb, ru # !! Doesn't work, parameter type is [string]
Instead, you have to initialize with 1 language and then add additional ones later, using the .Add() method:
# Create the list with initially just 'en-gb'...
$langlist = New-WinUserLanguageList en-gb
# ... and then add the other language, 'ru'
# Because the list is strongly typed, it is sufficient to pass the language
# identifier, which implicitly creates a new
# [Microsoft.InternationalSettings.Commands.WinUserLanguage] instance.
$langlist.Add('ru')
# Now you can modify the properties of $langlist[0] (en-gb)
# and $langlist[1] (ru)
# ...
# ... and pass the list of modified languages to Set-WinUserLanguageList:
Set-WinUserLanguageList $langlist
Alternatively, to avoid the .Add() call, you could have used:
$langlist = (New-WinUserLanguageList en-gb)[0], (New-WinUserLanguageList ru)[0]
Even though $langlist is then technically an array (a [System.Object[]] instance whose elements are of type Microsoft.InternationalSettings.Commands.WinUserLanguage), passing it to Set-WinUserLanguageList works, because it is implicitly converted to the required list type.

Applying an attribute to all parameters

I've got the following list of parameters for a SQL script. They're all mandatory, as you can see.
param(
[Parameter(Mandatory)][string]$dropLoc,
[Parameter(Mandatory)][string]$manifest,
[Parameter(Mandatory)][string]$accountName,
[Parameter(Mandatory)][string]$appSqlServer,
[Parameter(Mandatory)][string]$appDatabaseName,
[Parameter(Mandatory)][string]$oltpDatabaseName,
[Parameter(Mandatory)][string]$oltpSqlServerName,
[Parameter(Mandatory)][string]$appRootURL,
[Parameter(Mandatory)][string]$AppServiceDBKey,
[Parameter(Mandatory)][string]$reportDBSqlServerName,
[Parameter(Mandatory)][string]$udmInstanceName,
[Parameter(Mandatory)][string]$reportDBDataPath,
[Parameter(Mandatory)][string]$reportDBLogPath,
[Parameter(Mandatory)][string]$maxETL
)
But this is really lengthy and I don't like how I set each one mandatory individually. Does Powershell have a way to set an attribute to all parameters?

Parameters issue in script

Can someone tell what I am doing wrong in the below I wrote:
function set-harden {
[CmdletBinding(DefaultParameterSetName='NormalHardening')]
param (
[Parameter(ParameterSetName='DoNotRemoveFromDomain')]
[Parameter(ParameterSetName='PermitHTTP' ,Mandatory=$True)]
[Parameter(ParameterSetName='PermitHTTPS' ,Mandatory=$True)]
[switch]$DONOTRemovefromdomain,
[Parameter(ParameterSetName='PermitHTTP')]
[Parameter(ParameterSetName='DoNotRemoveFromDomain')]
[switch]$Permithttp,
[Parameter(ParameterSetName='PermitHTTPS')]
[Parameter(ParameterSetName='DoNotRemoveFromDomain')]
[switch]$Permithttps,
[Parameter(ParameterSetName='NormalHardening')]
$NormalHardening
)}
If($NormalHardening -eq ""){
Write-Host "Excellent!"
}
All I want to do is to let the user select -DONOTRemovefromdomain or -Permithttp or even -Permithttps. There could be a variety of options the user has to choose from.
When I run this below I get an error:
PS C:\Temp> set-harden -DONOTRemovefromdomain -Permithttp
set-harden : Parameter set cannot be resolved using the specified named parameters.
At line:1 char:1
+ set-harden -DONOTRemovefromdomain -Permithttp
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [set-harden], ParameterBindingException
+ FullyQualifiedErrorId : AmbiguousParameterSet,set-harden
Also, if I do not specify anything (so it should just go to the parameter NormalHardening) I get an nothing back:
PS C:\Temp> set-harden
PS C:\Temp>
You've specified two flags, DONOTRemovefromDomain and Permithttp that belong to two parameter sets, DoNotRemoveFromDomain and PermitHttp. The command parser has no way of knowing which parameter set you mean, so you get an error.
The reason you don't get an error when you don't specify anything is because you've set the default parameter set explicitly to NormalHardening. You've not set the Mandatory flag on the single parameter in this parameter set, and by default parameters are not mandatory so you're not seeing an error.
Instead of having all these parameter sets why not just have 2, one for the default and one for all the flags you want to set:
function set-harden {
[CmdletBinding(DefaultParameterSetName='NormalHardening')]
param (
[Parameter(ParameterSetName='Options')]
[switch]$DONOTRemovefromdomain,
[Parameter(ParameterSetName='Options')]
[switch]$Permithttp,
[Parameter(ParameterSetName='Options')]
[switch]$Permithttps,
[Parameter(ParameterSetName='NormalHardening')]
$NormalHardening
)}
If($PSCmdlet.ParameterSetName -eq "Options"){
Write-Host "Excellent!"
}
How, if the parameter set name is set to Options you can check and apply the flags. If it's set to NormalHarding then you know to use the $NormalHardening parameter.
Sean gave a good answer already about what's going on in your specific case, but I want to include some tips for troubleshooting parameter sets.
Get Help
Or more specifically, Get-Help. The parameter set syntax is automatically generated from the param block, so running Get-Help myFunction will show you how PowerShell is interpreting your parameter sets (how many, which parameters are mandatory or not in each set, etc.).
Trace the Call
If the sets look right but you're getting errors and aren't sure why, let PowerShell show you how it's binding parameters:
Trace-Command -Name ParameterBinding -Expression { Set-Harden -Permithttp } -PSHost
That can give you great insight on what's going on, and lead you to how you might fix that (or help you realize that you can't).