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