Microsoft.WinGet.Client 0.1.0-alpha

[denelon]

Hey everyone,

We still have lots of work to do here. I decided to go ahead and ship the version with this latest WinGet Preview:
https://www.powershellgallery.com/packages/Microsoft.WinGet.Client/0.1.0-alpha

Feel free to have discussions here.

As you encounter issues, please create individual reports so we can track them separately.

[rollingmoai]

Are the versions tied to a specific release (like in the GitHub releases)? Or can I use 0.1.0-alpha on the latest Winget stable?

[denelon]

I'd suggest using one of the latest preview releases of WinGet with the PowerShell modules. As we're building them, we're making improvements to the COM APIs they are calling.

[doctordns]

Why not produce a complete package - winget itsesslf and the cmdlets?

[denelon]

That might be possible once we get everything implemented via COM. There are still a few outlying functions that aren't in place yet. It might also be confusing with one version of WinGet (App Installer) and a different version of the PowerShell module. I don't know of any other precedents set for something like this.

[doctordns]

It seems to me that to avoid confusion, there should be just one package - with the CLI and the Cmdlets. WInget-Client is all of that or should be. The package is hardly going to be huge. To me the bottom line is that it will reduce confusion: If you produce two packages that are somehow interdependent, I can promise you you will get issues raised as a result :-))

[rollingmoai]

According to the Quick Start Guide in https://github.com/microsoft/winget-cli/tree/master/src/PowerShell/Microsoft.WinGet.Client, the module requires Powershell and not Windows PowerShell. But the minimum version that is specified in the PowerShell Gallery is 5.1.0. (which is the Windows PowerShell version)

So what really is the minimum required version?

[denelon]

We need to update that to PowerShell 7.

[denelon]

I would like to get to a point where we work in "Windows PowerShell", but we have some challenges getting all the COM API .dlls in the right place.

[denelon]

• Microsoft.WinGet.Client depends on PowerShell 7 #3183

[doctordns]

Is Winget going to be supported in Windows PowerShell?

As someone highly pro-Win7, I have been waiting for some app to be PS7+ only. That said, it cuts out a whole lot of potential users (who use the installed version of (wWndows) PowerShell exclusively.

[denelon]

I would like to be able to support Windows PowerShell, but that's not as high a priority as getting parity with the CLI capabilities.

[doctordns]

A first suggestion - please consider renaming the module as just WinGet. A 32-character module name is sub-optimal.

[denelon]

We didn't want to cause confusion or a conflict:
https://www.powershellgallery.com/packages/WinGet/0.0.8

We're looking at having a top-level module for:

• Microsoft.WinGet

Then specific modules logically in that one would be:

• Microsoft.WinGet.Client - The WinGet client module.
• Microsoft.WinGet.DSC - DSC Resource for installing / configuring WinGet.
• Microsoft.WinGet.Source - The module for working with REST sources.
• Microsoft.WinGet.Create - The module for working with manifests and submitting them to the community repository or a REST source.

[doctordns]

I get it but it does make discovery that little bit harder. Oh well.

[doctordns]

Having looked at some of the help text from the cmdlets. The help text can be improved:
. Include a complete description of each cmdlet
. Have a full description of each parameter
. Have at least one and preferably more examples.

As an aside, will you localise the help text?

[denelon]

I'm not sure what implications there are for localization within help text.

[doctordns]

Localising help means translating the help text to non-EN-US languages and including those translations in the module. PowerShell does a great job handling this, but you must design it into the module.

As it turns out, the PowerSheel team have some great guidance for this: https://learn.microsoft.com/en-us/powershell/scripting/developer/help/writing-help-for-windows-powershell-modules?view=powershell-7.3

Also, it looks like the module does not support updatable help either. You could consider fixing this.

[denelon]

• Localizing help and making it updatable #3206

[doctordns]

This is more of a question rather than an issue. I used Get-WingetPackage - and was somewhat surprised to see I had a bunch. But I had not used Winget to do anything (yet!).. So my question is: what packages will Get-WInGetPackage return in the first instance?

[denelon]

WinGet leverages the registry entries behind "Windows Apps & Features". You should see all "installed" packages that are reported to Windows. For those packages with a mapping to a WinGet source, you would see the source. We don't have full fidelity mapping with the Microsoft Store exposed yet, but we would still show they have been installed.

[doctordns]

The Help text for the cmdlet n seeds to make this clear. Personally, I think this is a bug. If I use Get-Package, I get just those packages installed by Instatll-Package. But Get-WingetPackage returns packages installed by other mechanisms. At a very minimum, Get-Package and Get-WIngetPackage should be have similarly.

As an aside, can I update, using winget, some package that winget did NOT install?

[denelon]

Yes, WinGet is intended to understand what is on the system (assumes proper registry entries for Windows Apps & Features) and work with software even when it was installed by another mechanism.

[doctordns]

please ensure the help text says so.,

[denelon]

• Add more context to Get-WinGetPackage help #3207

[megamorf]

The module does not work as I would expect it to. A very common use case in PowerShell is to run a command that returns a collection of objects, we then filter that collection and finally pipe it into another cmdlet for further processing:

Expected: Get list of packages that can be updated and update them
Actual: The Update-WingetPackage cmdlet does not process pipeline input properly (wrong property binding?)

PS> Get-WinGetPackage -ov pkgs | where IsUpdateAvailable -ov pkgsToUpdate | ft -au

Name                                            Id                          Version          Available      Source
----                                            --                          -------          ---------      ------
Docker Desktop                                  Docker.DockerDesktop        3.5.2            4.18.0         winget
Everything                                      voidtools.Everything        1.4.1.935        1.4.1.1022     winget
f.lux                                           flux.flux                   Unknown          4.120          winget
Git                                             Git.Git                     2.22.0.windows.1 2.40.1         winget
IrfanView                                       IrfanSkiljan.IrfanView      4.53             4.62           winget
KeePass                                         DominikReichl.KeePass       2.40             2.53.1         winget
Microsoft Edge                                  Microsoft.Edge              112.0.1722.64    112.0.1722.68  winget
Notepad++                                       Notepad++.Notepad++         7.7.1            8.5.2          winget
SumatraPDF                                      SumatraPDF.SumatraPDF       3.1.2            3.4.6          winget
VLC media player                                VideoLAN.VLC                < 3.0.17.4       3.0.18         winget
Vim                                             vim.vim                     8.2              9.0.1504       winget
PDFCreator                                      pdfforge.PDFCreator         3.3.0            4.4.2          winget
Microsoft Visual C++ 2005 Redistributable (x64) Microsoft.VCRedist.2005.x64 8.0.56336        8.0.61000      winget
Microsoft Visual C++ 2013 Redistributable (x86) Microsoft.VCRedist.2013.x86 12.0.40660.0     12.0.40664.0   winget
Glimpse                                         Glimpse.Glimpse             0.1.2            0.2.0          winget
Microsoft Visual C++ 2005 Redistributable       Microsoft.VCRedist.2005.x86 8.0.56336        8.0.61001      winget
Inkscape                                        Inkscape.Inkscape           0.92.4.0         1.2.2          winget
PuTTY                                           PuTTY.PuTTY                 0.72.0.0         0.78.0.0       winget
Windows 10 Update Assistant                     Microsoft.UpdateAssistant   1.4.9200.23072   1.4.19041.1555 winget
Microsoft Visual C++ 2013 Redistributable (x64) Microsoft.VCRedist.2013.x64 12.0.40660.0     12.0.40664.0   winget

PS> $pkgsToUpdate | Update-WinGetPackage -Verbose
VERBOSE: Performing the operation "Update-WinGetPackage" on target "Docker Desktop [Docker.DockerDesktop] Version 3.5.2".

CorrelationData            :
ExtendedErrorCode          : System.Runtime.InteropServices.COMException (0x8A15004F): 0x8A15004F
InstallerErrorCode         : 0
RebootRequired             : False
Status                     : NoApplicableUpgrade
NativeObject               : WinRT.ObjectReference`1[WinRT.Interop.IUnknownVftbl]
HasUnwrappableNativeObject : True
AdditionalTypeData         : {}

Update-WinGetPackage: No versions matched the given value: 1.4.1.935

[denelon]

Yeah, it's not all wired up yet.

[doctordns]

That looks liKE a bug! ;-0)

[zbalkan]

The default behavior of the Update-WingetPackage looks wrong. It should not try to upgrade all packages but only the ones with update available. So it should be a a syntactic sugar for Get-WinGetPackage | Where-Object -Property IsUpdateAvailable -eq $true | ForEach-Object { Update-WinGetPackage -Id $_.ID } , not Get-WinGetPackage | ForEach-Object { Update-WinGetPackage -Id $_.ID }. Currently it gets all the packages and then throws an exception.

P.S: Excuse me for the bad redaction.

[denelon]

• Update-WinGetPackage default behavior #3231

[leoniDEV]

Install-WinGetPackage has a -Scope parameter which can be Any, System, SystemOrUnknow, User, UserOrUnknow

I don't know exactly what mean Any, SystemOrUnknow, UserOrUnknow, an if they are really necessary, but I thik this parameter need to follow conventions we already have.

In Powershell, for the -Scope parameter, typically uses CurrentUser and AllUsers (like for Install-Module); Winget for the --scope parameter of the install command, uses machine or user.

So for Install-WinGetPackage the -Scope parameter need to be consistent with the Powershell convention or with the Winget convention

If the *OrUnknow values are necessary, they could be CurrentUserOrUnknow/AllUsersOrUnknow or UserOrUnknow/MachineOrUnknow.

My preference is for consistency with Powershell so I think CurrentUser and AllUsers are more appropriate.

[denelon]

Making that kind of change would be considered breaking for the schema. We're trying to keep the schema version similarly aligned with the client version. We've run into all kind of edge cases where installers might implement their own behaviors for scope and don't necessarily honor or support switches. Unfortunately, there are several different conventions to follow, and it's one of those scenarios where we're not likely to be able to make everyone happy. I do think the "CurrentUser" and "AllUsers" do make sense. I think we will visit all the enumerations in the schema as a part of looking seriously at a 2.0 release when we're ready to do that.

Related Issues:

• Handle scope better #3240
• Breaking changes to properly justify a 2.0 release #2128

[leoniDEV]

What I propose don't seem a breaking for the schema (at least not bigger than the one already made), the current implementation of the install cmdlet in Powershell seems a breaking of the schema.
The last version of the manifest, for the Scope field, reports that the accepted value are user and machine so way the Powershell cmdlet accept Any, System, SystemOrUnknow, User, UserOrUnknow?

If you don't want to break the manifest schema and think that the values of the parameters need to be consistent with the Winget CLI, why the -Scope parameter accept 4 values (instead of 2) and none of them resembles the ones accepted by the CLI and are completely different than the ones suggested by the manifest schema?

If you think that is acceptable that the CLI and the Powershell cmdlets slightly diverge (as it seems with the current implementation of the install cmdlet) why don't be consistent with the convention already in use in Powershell?

[denelon]

Ahh, I misinterpreted what was suggested. Yes, changing the arguments for the PowerShell cmdlets would be perfectly fine. And, yes, I'm completely fine with the PowerShell cmdlets having different syntax than the CLI. We want the PowerShell module to follow the PowerShell idioms so users can quickly reason about what it's doing and to feel as "native" as possible for PowerShell users.

[doctordns]

to some degree, I do not care if making great PowerShell cmdlets mean your scheme has to change. You were wanted TWO years ago or more that this could happen if you did not focus early enough on the cmdlets, etc. It is to be regretted that your console application was developed to be deliberately not compatible. Please create good cmdlets and fix the Console Application where that is a good thing,. There should not be inconsistency by design.

[ruudhanegraaf]

Quick question: Is there a PowerShell equivalent on the roadmap for the 'winget show' command?

[denelon]

I don't believe so.
https://github.com/microsoft/winget-cli/issues?q=is%3Aissue+is%3Aopen+label%3AIssue-Feature+label%3APowerShell

Feel free to create one 😊

[soroshsabz]

How to use this Package like a PackageProvider?

I like to do something like below

Install-PackageProvider Microsoft.WinGet -Force -Scope CurrentUser

and then I like to use standard package management command like

Find-Package
Install-Package
Update-Package
...

@denelon

[soroshsabz]

related to #1088

[denelon]

There is no official package provider for WinGet to work with OneGet. FYI, OneGet has been deprecated https://github.com/OneGet/oneget#announcement.

[ThomasNieto]

@soroshsabz there is a OneGet package management replacement called AnyPackage which has a WinGet provider.

[eabase]

Any news or updates here, for fixing the scope usage on winget?
I still don't get why winget list can't also provide a scope column?

[denelon]

This discussion is about the first version of the Microsoft.WinGet.Client PowerShell module.

Are you interested in the bug:

• winget list --scope=machine throws 0x80070005 : unknown error when non-admin #3052

Or are you requesting a new feature to have the ability to add installed package scope to the list command? If it's the former, please add your 👍to that bug. If it's the latter, please file a feature request.

[eabase]

Bump