Improve winget output (type: system.array) to be actionable by PowerShell

[Karl-WE]

Description of the new feature / enhancement

Would like to see the winget output stored with properties, so one can work with them in PowerShell. The current output saved into a variable is of type System.Array but saved unstructured, more like with 'start-transcript'

• The output even includes any output including characters from the progress bar.
• Currently the output is saved "as-is" this may include Unicode issues as. Reference: screenshots below.

Affected products

winget cli winget PowerShell module Tested with v1.8.924-preview

Background

Until #4507 never bothered to combine winget with other PowerShell commands. But now a customer request made it a requirement.

Examples

$apps = winget upgrade $apps = winget list $app1 = winget list Putty.Putty

Native Microsoft Terminal output of winget upgrade

This results into a variable of type system.array. It is not possible to fetch data from the columns

$app1.GetType()

IsPublic IsSerial Name BaseType -------- -------- ---- -------- True True Object[] System.Array

Variable output of $app1 from $app1 = winget list Putty.Putty

Proposed technical implementation details

Feature request 1: Currently if I need to lookup what's the latest version of Putty this is not an easy task when automated via PowerShell. One can only vaguely use -match / -like It should become possible to use the data of columns and rows.

When the output would be structured, I could use regular PowerShell code to identify the content, like:

#identify if Putty is installed and matches a specific version $apps | Where-Object name -eq "Putty.Putty" and version -like "*0.78*"

or

#identify if Putty is installed and return the latest available version ($apps | Where-Object name -eq "Putty.Putty").available

and so on.

Feature request 2: The column names should be static (en-US) and independent from the console output, which is localized. If column names would be localized as per output, this would make automation very difficult when scripting is applied on a fleet of OS with different languages / language packs or native OS language for Windows Client or Windows Server.

[github-actions[bot]]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

• Change return type of lists from winget (#1506), similarity score: 0.77

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[Karl-WE]

GitHub actions mentioned #1506 and within this #221. Both closed. Unfortunately, miss to see the request of 1506 satisfied by any mentioned PR, nor was I aware about a potential duplicate. AI works great :)

[stephengillie]

Please consider using the WinGet PowerShell cmdlets, such as Find-WinGetPackage, as they provide PSObjects.

[Karl-WE]

@stephengillie that's great news. Thank you for sharing this. If the work is already done, I certainly tend to close this FR.

Right now, I wonder, how to deploy winget PS module at scale and keeping it updated.

Hindrances I can think of right now, are

• blocked psgallery / nuget (some org's security concerns)
• limited local permissions
• deploy and maintain PS module on Windows Server (AD) vs Clients (AD less / Entra joined only).

Could consider is a scheduled task to do that with a PS script.

Any better ideas?

[denelon]

I know there is work in progress to support Azure Container Registry (ACR) as a "local"/"private" PowerShell Gallery. It's also possible to host NuGet packages in Azure Dev Ops, and there are some commercial products as well.

The Microsoft.WinGet.Client module works for PowerShell 7 (limited capabilities in Windows PowerShell). We've got work to figure out how to make everything work in Windows PowerShell. Microsoft.WincGet.Configuration handles configuration and doesn't depend on the client directly.

[Karl-WE]

The PS7 dependency is fair. It seems like Windows Server 2025 will not likely be shipped with PS7.

@denelon how do you think about whether it's feasible to keep up his feature request, or close and point to PS module, despite the dependencies of nuget, psgallery and, best case, PS 7?

[Karl-WE]

Another similar request is #964 which also emphazise why PowerShell Module of winget is not a good generic solution and it would make sense to triage this.