Microsoft.WinGet.Client vs. WinGet package provider

[marco-eckstein]

I use PowerShell 7 and have installed the Microsoft.WinGet.Client module via Install-Module Microsoft.WinGet.Client. Now that I try to add WinGet as a provider for package management via Install-PackageProvider WinGet, I get this error:

Install-PackageProvider: The following commands are already available on this system:'Find-WinGetPackage,Get-WinGetPackage,Get-WinGetSource,Install-WinGetPackage,Uninstall-WinGetPackage,Update-WinGetPackage'. This module 'Cobalt' may override the existing commands. If you still want to install this module 'Cobalt', use -AllowClobber parameter.

I don't want to create a mess. What is the proper way of using Microsoft.WinGet.Client with the WinGet provider together? Or should I simply uninstall Microsoft.WinGet.Client before I install the package provider, because the package provider has all the features of Microsoft.WinGet.Client anyway?

[norsemangrey]

I think you need to install WinGet via MSStore or Appx first before you can install the PS module.

[marco-eckstein]

WinGet had been installed first anyway. My question is about the PowerShell module and the package provider.

[denelon]

The Microsoft.WinGet.Client module isn't a packageProvider for PowerShell. I believe someone from the community built https://www.powershellgallery.com/packages/WinGet/0.0.8 as a package provider, but I don't know if they are actively continuing to work on it.

[marco-eckstein]

Yes. The Microsoft.WinGet.Client module is a PowerShell Module for the WinGet. I installed it to have PowerShell module for WinGet.

[marco-eckstein]

I close this discussion without an answer because in the meantime I have found out that PackageManagement (aka OneGet) is deprecated anyway and has been superseded by the community project AnyPackage. Consequently, the package provider WinGet is obsolete too and has been superseded by AnyPackage.WinGet. I still have to see whether that one is compatible with the Microsoft.WinGet.Client module.