Is there a sensible way to restrict the parameter type used for a function when it may be encapsulated in a CimInstance
?
e.g. Say I have a method such as below:
function Add-DaclAce {
[CmdletBinding()]
[OutputType([System.Void])] #just for the MVP
Param (
[Parameter(Mandatory)]
[ValidateScript({$_.CimClass.CimClassName -eq 'Win32_SecurityDescriptor'})]
[System.Management.Infrastructure.CimInstance]$SecurityDescriptor
,
[Parameter(Mandatory)]
[ValidateScript({$_.CimClass.CimClassName -eq 'Win32_ACE'})]
[System.Management.Infrastructure.CimInstance]$NewDaclAce
)
$SecurityDescriptor.DACL.Add($NewDaclAce) | Out-Null
}
Question?
- Is there a better way to enforce the type of the parameters; i.e. using the parameter type, instead of a validation script?
- Is there a way to make the implementation agnostic of CIM vs WMI, so that it only cares that the object is a SecurityDescriptor/Access Control Entry?
i.e. My requirement is only that the first parameter be a security descriptor, and my second an ACE; but because I'm using CIM to fetch these in my current implementation, they happen to be of type CimInstance
. I then wish to enforce that they represent the correct underlying objects, so have to use ValidateScript
to check the CimClass
. However, the use of CIM is an arbitrary detail from the perspective of this function; it