Installed packages not identified as available on Wingetty since there is no ProductCode on each package installer

[anillo-uv]

First congratulations on this project, I am looking forward for development of it. It solves one of biggest issues now with Microsoft Package Management.

I noticed when joining systems to the WinGetty repo and listing for Softwares already installed they appear as SearchId {ProductCode} and not as Wingetty Identifier Publisher.Name, so I cant handle them on winget until I manually uninstall them from system, then install using the Winget install command.

I see on the Official Microsoft winget Manifest repository, most of the packages, each version, it contains ProductCode identifier explicitly stated there. So somehow when winget list is used, it will recognize if the Packages are in the repo.

Solution for this could be to have an extra field whenever new version of package is uploaded to wingetty, so optionally we could state the right ProductCode, like for instance ProductCode: '{7d607fb4-7e28-4c7a-a92f-3fcdaf555faf}' for Microsoft.VCRedist2015

Thanks,

[anillo-uv]

Just to complement, add more information on this: Reading the wingetty code I understand each installed is stored with architecture, installer_type, file_name, installer_sha256, scope.....

Adding optional ProductCode could enhance this. But here the part missing also would be to reply to winget restAPI to reply for each installer InstallerSha256 and ProductCode

[randywatson1979]

I am also interrested in this. I have uploaded a new package with a minor version update, but it does not appear in the available column in "winget upgrade" list. The new version of the package does show up when I run "winget search".

[gkandler]

I encountered this as well and am now using winget pro; it doesn't seem to have this issue.

[thilojaeggi]

Do you have any example of software where this fails?

[randywatson1979]

We do not have an example at hand unfortunately, but the application is made in Cordova electron platform and built as .exe file.

[thilojaeggi]

Okay, as I've noticed is that the ProductCode normally only gets used by MSI installers according to the winget docs, although the VCRedist mentioned above for example is an exe.
Just to note, it looks like the ProductCode needs to be set per Installer.

[anillo-uv]

I investigated little bit more, if manifest JSON that WinGetty replies to winget command would include "ProductCode" inside "Installers" section, this I think will solve the issue.

It is very easy to find from a system where that specific app was installed the ProductCodeID, just launching wmi or Powershell command, to capture it each time a new installer is uploaded into WinGetty

Absolutely right, each installer would have different Product Code ID. I think it could be an optional argument when uploading a new installer into one package, then winGetty will reply manifest including the ProductCode or not depending if has been filled in.

This will be mandatory for those who would like to transition Windows Client pool into winget, I performed POC during last two weeks and I see no other possibility to migrate from pool with already installed apps to start using winget as software distribution for an Enterprise company. Since otherwise current apps arent detected, so you cannot push the upgrade to newer versions of same applications (packages) otherwise.

Thanks,