microsoft / winget-cli

WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
https://learn.microsoft.com/windows/package-manager/
MIT License
23.38k stars 1.46k forks source link

Packages not being recognized by winget: what to do? #3754

Closed CanePlayz closed 1 year ago

CanePlayz commented 1 year ago

Brief description of your issue

I have some packages installed which are also available from winget, but aren't picked up by it. winget list for those packages yields

Name                                          ID                                                   Version          Source
---------------------------------------------------------------------------------------------------------------------------
MyHeritage Family Tree Builder                Family Tree Builder                                  8.0.0.8636
Google Play Spiele (Beta)                     GooglePlayGames                                      23.9.1265.3
ROCCAT SWARM                                  InstallShield_{6FB8005D-F942-4BFB-AD75-5DA08E5454D9} 1.94.330

At least that's what I'm assuming because it doesn't change the ID to the winget one (which it does for all the ones with winget under Source).

What would I have to change in the manifest to make that work? Unfortunately, I don't know at all how the matching of local packages to winget manifests is handled by winget.

I don't really need a fix on the winget side, I'm rather curious in how the matching process works and how I can fix it for specific packages.

Steps to reproduce

Install one of the packages affected

Expected behavior

Winget recognizes them

Actual behavior

Winget doesn't recognize them

Environment

Windows: Windows.Desktop v10.0.25967.1000
System architecture: X64
Package: Microsoft.DesktopAppInstaller v1.21.2771.0
Trenly commented 1 year ago

PackageName should match the Name shown in Control Panel Publisher should match the Publisher shown in Control Panel PackageVersion should match the version shown in Control Panel PackageID should match the GUID from the registry entry - you can use the function below to find product codes

function Get-ARPTable {
  $registry_paths = @('HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*','HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*', 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*', 'HKCU:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*')
  return Get-ItemProperty $registry_paths -ErrorAction SilentlyContinue |
      Where-Object { $_.DisplayName -and (-not $_.SystemComponent -or $_.SystemComponent -ne 1 ) } |
      Select-Object DisplayName, DisplayVersion, Publisher, @{N='ProductCode'; E={$_.PSChildName}}, @{N='Scope'; E={if($_.PSDrive.Name -eq 'HKCU') {'User'} else {'Machine'}}}
}
CanePlayz commented 1 year ago

PackageName should match the Name shown in Control Panel Publisher should match the Publisher shown in Control Panel PackageVersion should match the version shown in Control Panel PackageID should match the GUID from the registry entry

Ohh thanks, now it all makes sense. I thought those attributes were just the same ones as in the folder structure/the Package Identifier. Now I can fix those.

CanePlayz commented 1 year ago

@Trenly Just two more questions:

  1. Where should I put PackageID? I cannot find it in the manifest schemas.

  2. If the German package name is different from the English one, should I just add a new locale file where everything is the same except for the PackageName?

Trenly commented 1 year ago

@Trenly Just two more questions:

  1. Where should I put PackageID? I cannot find it in the manifest schemas.
  2. If the German package name is different from the English one, should I just add a new locale file where everything is the same except for the PackageName?

PackageID is the PackageIdentifier, I mistakenly used the shorthand

Yes, adding a new locale file would be a good start. If there are separate installers for English and German, then adding a new installer node and using AppsAndFeaturesEntries would be the better option

CanePlayz commented 1 year ago

PackageID is the PackageIdentifier, I mistakenly used the shorthand

Yeah, I thought so, but isn't the PackageIdentifier the winget identifier of the package and not its GUID?

Yes, adding a new locale file would be a good start. If there are separate installers for English and German, then adding a new installer node and using AppsAndFeaturesEntries would be the better option

Thanks.

Trenly commented 1 year ago

PackageID is the PackageIdentifier, I mistakenly used the shorthand

Yeah, I thought so, but isn't the PackageIdentifier the winget identifier of the package and not its GUID?

I am so sorry. I'm on too few hours of Sleep. I've been saying PackageID when I really mean ProductCode

CanePlayz commented 1 year ago

PackageID is the PackageIdentifier, I mistakenly used the shorthand

Yeah, I thought so, but isn't the PackageIdentifier the winget identifier of the package and not its GUID?

I am so sorry. I'm on too few hours of Sleep. I've been saying PackageID when I really mean ProductCode

Ahh, that makes sense now. And no need to be sorry, thanks for all of your help and sleep well. 😴😄