Relevant area(s)
- DSC Resource
- WinGet CLI
- COM API
Description of the new feature / enhancement
Implement native DSC v3 command-based resources directly in the WinGet client. This eliminates the ~92s adapter overhead per resource and enables full configuration-as-code parity with the CLI.
Key resources needed:
- Microsoft.WinGet/Package — Single package desired state (install/upgrade/uninstall)
- Microsoft.WinGet/PackageList — Declare an entire machine's desired package state in a single resource block
- Microsoft.WinGet/Source — Package source configuration
- Microsoft.WinGet/Settings — WinGet settings desired state
- Microsoft.WinGet/Pin — Package pin management
The PackageList resource is critical — it enables expressing 'this machine should have exactly these packages' declaratively, which is the most-requested configuration-as-code scenario.
Currently, WinGet DSC resources (Microsoft.WinGet.DSC PowerShell module) are class-based and require the PowerShell adapter in DSC v3, resulting in ~92s per resource invocation vs. ~3-5s for native v3 resources.
Proposed technical implementation details
Add a \winget dsc\ subcommand that implements the DSC v3 command-based resource protocol:
- \winget dsc get --resource Package\ — reads JSON from stdin, outputs current state
- \winget dsc set --resource Package\ — converges to desired state
- \winget dsc test --resource Package\ — returns compliance status
Ship JSON resource manifests (.dsc.resource.json) alongside the WinGet executable so DSC v3 discovers them on PATH without any adapter.
Related issues: #3401, #5806
Relevant area(s)
Description of the new feature / enhancement
Implement native DSC v3 command-based resources directly in the WinGet client. This eliminates the ~92s adapter overhead per resource and enables full configuration-as-code parity with the CLI.
Key resources needed:
The PackageList resource is critical — it enables expressing 'this machine should have exactly these packages' declaratively, which is the most-requested configuration-as-code scenario.
Currently, WinGet DSC resources (Microsoft.WinGet.DSC PowerShell module) are class-based and require the PowerShell adapter in DSC v3, resulting in ~92s per resource invocation vs. ~3-5s for native v3 resources.
Proposed technical implementation details
Add a \winget dsc\ subcommand that implements the DSC v3 command-based resource protocol:
Ship JSON resource manifests (.dsc.resource.json) alongside the WinGet executable so DSC v3 discovers them on PATH without any adapter.
Related issues: #3401, #5806