0

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

JohnLBevan
  • 22,735
  • 13
  • 96
  • 178
  • 1
    I asked this exact question a while back, let me find it for you. – Maximilian Burszley Aug 14 '19 at 12:52
  • Nice one, thanks; sorry, didn't find that when searching. Closing mine as a duplicate – JohnLBevan Aug 14 '19 at 12:54
  • 1
    As for your question about implementation agnostic, I'm not sure if that's solved for. Maybe parameter sets that can accept one or the other? The `#..` path remains the same, but the type is different. – Maximilian Burszley Aug 14 '19 at 12:56
  • 1
    Thanks. The answer to your question was enough for my requirement / part 2 of my question was more an ideal than a need. Sadly the `System.Object` approach didn't work, and it seems that the only common ancestor with WMI's ManagementClass; good shout though. – JohnLBevan Aug 14 '19 at 13:08

0 Answers0