Passing object properties to Hashtable of class-based PowerShell resource #709

Activity

1. JohnMcPMS

   added

   Issue-BugSomething isn't workingSomething isn't working

   Need-Review

   on Mar 17, 2025
2. Gijsreyn commented on Mar 18, 2025

   

   Gijs Reijn (Gijsreyn)

   on Mar 18, 2025

   Collaborator

   More actions

   Hi JohnMcPMS. I think you found something interesting. I was trying to reproduce the config part, and what you probably did in the first place, was something like this:

   $schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
   resources:
   - name: UserSettings
     type: Microsoft.WinGet.DSC/WinGetUserSettings
     properties:
       Action: 'Partial'
       Settings:
         experimentalFeatures:
           dsc3: true

   This gives the error you reported, but it should have been:

   $schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
   resources:
   - name: Use class PowerShell resources
     type: Microsoft.DSC/PowerShell
     properties:
       resources:
       - name: PowerShell 7 Preview
         type: Microsoft.WinGet.DSC/WinGetUserSettings
         properties:
           Action: Partial
           Settings:
             experimentalFeatures:
               dsc3: true

   This gives the same error message as the dsc resource command. Anyway, back to the interesting part. I was looking were the issue is going wrong, and it's on the lines responsible for converting the following in the psDscAdapter.psm1:

   if ($DesiredState.properties) {
       # set each property of $dscResourceInstance to the value of the property in the $desiredState INPUT object
       $DesiredState.properties.psobject.properties | ForEach-Object -Process {
           $dscResourceInstance.$($_.Name) = $_.Value
       }
   }

   The $DesiredState is of class dscResourceObject, which sets the properties default to psobject. You opened something interesting, because the properties in this case aren't compared against the actual class constructed with $dscResourceInstance = $resource::New().
   That's why you see the exception happening. To demonstrate the issue (and a workaround) a little bit more clearly, I simple added the following lines to convert the PSCustomObject to a hashtable:

   if ($DesiredState.properties) {
     # set each property of $dscResourceInstance to the value of the property in the $desiredState INPUT object
     $DesiredState.properties.psobject.properties | ForEach-Object -Process {
         if ($_.Value.GetType().Name -eq 'PSCustomObject') {
             $hashTable = @{}
             $_.Value.psobject.properties | ForEach-Object { $hashTable[$_.Name] = $_.Value } 
   
             $dscResourceInstance.$($_.Name) = $hashTable
         }
         else 
         {
             Write-DscTrace -Message "Setting property: $($_.Name) to $($_.Value.TypeNameOfValue)"
             $dscResourceInstance.$($_.Name) = $_.Value    
         }
     }
   }

   Then the result ends in what you're looking for:

   

   It however asks the fundamental question I guess: how does dsc.exe parse the specific object types towards adapted resources?

   Steve Lee (@SteveL-MSFT) or Mikey Lombardi (He/Him) (@michaeltlombardi) , what are your thoughts on?
3. JohnMcPMS commented on Mar 18, 2025

   

   JohnMcPMS

   on Mar 18, 2025

   CollaboratorAuthor

   More actions

   It was my understanding that the config commands would be more efficient if you explicitly wrapped all of your adapted resources, but that it was not necessary. It seems strange to me that it would be required via config, but one cannot even supply --adapter to the resource usage commands.
4. SteveL-MSFT commented on Mar 19, 2025

   

   Steve Lee (SteveL-MSFT)

   on Mar 19, 2025

   Member

   More actions

   JohnMcPMS the issue you are referring to is this #693 which I'm working on
5. SteveL-MSFT commented on Mar 19, 2025

   

   Steve Lee (SteveL-MSFT)

   on Mar 19, 2025

   Member

   More actions

   Gijs Reijn (@Gijsreyn) I think you are on the right track for a fix, can you create a PR with added test?

   👍React with 👍1Reacted by Gijs Reijn
6. Steve Lee (SteveL-MSFT)

   added this to the 3.1-Consider milestone on Mar 19, 2025
7. SteveL-MSFT commented on Mar 20, 2025

   

   Steve Lee (SteveL-MSFT)

   on Mar 20, 2025

   Member

   More actions

   This should be fixed by #713
8. Steve Lee (SteveL-MSFT)

   closed this as completedon Mar 20, 2025
9. Steve Lee (SteveL-MSFT)

   added

   Resolution-FixedThe issue is fixedThe issue is fixed

   and removed

   Need-Review

   on Mar 20, 2025