July 2022 Update

[denelon]

We've been digging deeper into calling the COM API via PowerShell.

We have several cmdlets working in PowerShell 6 and 7 against the COM API rather than the winget client so we can provide rich objects. I've shared a couple of screenshots below. There were some challenges referencing the "winmd" file that we had to resolve. We're still tackling challenges and looking at how to support Microsoft.WinGet.Client in PowerShell 5.1.

I'm expecting to get a subset of this released starting with Windows Package Manager 1.4-preview releases.

I've got a list of candidates below for getting native PowerShell support completed:

• Create the wrapper/object factory in COM to make it easier to work with multiple versions of PowerShell
• Continue migrating all capabilities into the COM API
• Ensure all new behaviors are implemented into the COM API
• Expose something like "--json" for commands to have output delivered as JSON in the winget CLI (nice to have)
• Start modifying cmdlets to use the COM API with rich objects for PowerShell
• Build appropriate tests for PowerShell cmdlets
• Sign cmdlets
• Automate building, testing, and signing cmdlets
• Start publishing signed modules/cmdlets with GitHub releases as we make progress
• Publish modules in PowerShell gallery

[ethanbergstrom]

Very exciting! Looking forward to deprecating my Crescendo module, because trying to parse the native client's output is extremely painful.

[whitTech]

OMGosh, Ethan. Hats off to you. Having to perform string parsing/manipulation to convert to highly reliable structured data is a special kind of awful task. You're a better person than I!

[kilasuit]

Some comments

• perhaps drop WinGetPackage to just WGPackage or better yet alias it for lazy people on the cmdline
• also why do you need to make use of COM at all? This confuses me a little as its a really old tech that we really shouldn't need to use for perfromance reasons & doesn't work on PowerShell 7 unless using the remoting tech to go back into PowerShell 5.1

[RichiCoder1]

And for some additional context, COM underpins a lot of modern development on Windows (see WinUI and WinAppSdk) and provides an excellent tool for cross-language interoperability. Here being used for C++ to C# interop without something ugly like exposing a C-based API. It's old, but still plenty useful, used, and performant.

[kilasuit]

Thanks @RichiCoder1 I just wasn't aware of that you see

[whitTech]

Disagree. Please do not go substituing Powershell's beloved verbosity with arbitrary abbreviations. There is a reason why I can teach Powershell to nearly anyone I work with even if they're a complete newb to the command line: English-like verbosity. This is also the same reason why I can remember the names of 100 cmdlets to every 1 of a Batch or Linux tool.

If you want to alias your environment to the max, by all means, but the baseline verbosity that is part of what defines Powershell needs to stay.

Also, tab completion and sophisticated ides are a thing, so I do wonder why longer commands are a problem for anyone in 2022?

[kilasuit]

@whitTech I've updated my comment to make it clearer of what my intent really was.

Not all people use tab completion (due to often not knowing about it) and whilst I agree with you about this There is a reason why I can teach Powershell to nearly anyone I work with even if they're a complete newb to the command line: English-like verbosity. This is also the same reason why I can remember the names of 100 cmdlets to every 1 of a Batch or Linux tool. I know this as I have been doing the same in the UK and international PowerShell Community since late 2015. (may be worth you reading my GitHub readme 😉)

Also 100% agree on this If you want to alias your environment to the max, by all means, but the baseline verbosity that is part of what defines Powershell needs to stay.

[whitTech]

I'm glad we're predominantly in agreement.

And yes, I took a glance at your readme after posting. Full respect to you for any and all contributions you've made to Powershell's development and the associated community. Also, I found your username explanation somewhat amusing.

[soroshsabz]

Why does not use OneGet to get integration with package managing system in PowerShell? I think Find-Package and Install-Package and another commands is very easier to use and make native scenes.

[ethanbergstrom]

Regarding this - there is an unofficial OneGet provider for WinGet I maintain, with the lower-level integration with winget.exe through a second Crescendo-based module.

Once this new official module is released, I plan to replace the OneGet provider's Crescendo module dependency with this new module, but it should still support interacting with WinGet packages and source information via the standard OneGet cmdlets and DSC resources.

[soroshsabz]

Thanks a lot :)

[denelon]

@ethanbergstrom (or anyone else familiar with PowerShell DSC) I'd like to get a call together to understand how you are using PowerShell DSC. I've asked the team to look into creating a DSC resource for WinGet and I'd like to gather some data points on how it would be used, and how other package managers could be supported in a similar fashion.

If you are interested, please e-mail me directly so I can find a good date/time.

[jantari]

@denelon July and August have come and gone, are there any updates on PowerShell support worth sharing?

[denelon]

@jantari thanks for the ping. I don't think enough has changed yet to demonstrate real progress, but I will pull an update together.

[MartinSGill]

@denelon, I'm a bit curious about the approach you are using. I've not had much time to look through the code so it's entirely possible I'm missing the obvious as to why my thoughts on the matter might be wrong.

Wouldn't a quick win for PS support (and any other scripting language) be to add JSON as an output option?

winget list -o json | ConvertFrom-Json | Format-Table

The next step would then be to wrap it and cast it

class WinGetPacakage {
  [string]$Name
  [string]$Id
}

function Get-WinGetPackage {
   [WinGetPackage](winget list -o json | ConvertFrom-Json)
}

Also if you need to call COM, wouldn't creating the PowerShell module in C# and using the interop classes be easier than trying to access COM from PowerShell? Wouldn't that also solve the Powershell 5.1 / 7 issues by targeting different .NET frameworks during the build?