PowerShell Module Full Parity with WinGet CLI

[denelon]

Relevant area(s)

• PowerShell Module
• COM API

Description of the new feature / enhancement

The WinGet PowerShell module (Microsoft.WinGet.Client) should achieve full functional parity with the WinGet CLI. Today, several CLI capabilities have no PowerShell equivalent, blocking adoption by IT administrators and configuration-as-code workflows that rely exclusively on PowerShell (Intune, SCCM, Azure Automation, DSC).

Key gaps include:

• No PowerShell equivalent for \winget configure\ operations (test, validate, show)
• Missing cmdlets for pin management
• No cmdlet for \winget download\
• Missing \winget repair\ support in the module
• No PowerShell equivalent for \winget settings\ management
• Limited source management beyond basic add/remove

Enterprise automation operates in PowerShell-only contexts where shelling out to \winget.exe\ is unreliable (especially in SYSTEM context) or architecturally inappropriate. Full parity unblocks enterprise adoption.

Proposed technical implementation details

Add missing cmdlets using the existing COM API (Microsoft.Management.Deployment):

• \Test-WinGetConfiguration, \Assert-WinGetConfiguration, \Get-WinGetConfiguration\
• \Save-WinGetPackage\ (download)
• \Repair-WinGetPackage\
• \Add-WinGetPin, \Remove-WinGetPin, \Get-WinGetPin, \Reset-WinGetPin\
• \Export-WinGetSettings, \Set-WinGetSetting\
• Enhanced source management cmdlets with full parameter parity

All cmdlets should support SYSTEM context operation for enterprise automation scenarios.

[Trenly]

• Related to Add "Limit-WinGetPackage" #3234

[Trenly]

• Is there a Winget Show PowerShell equivalent? #3823
• Add winget hash to PowerShell Module #4273
• Add Configure Support to PowerShell client. #5758