New package: MSI.MSICenter version 2.0.72 (Uses rotating hash)

[Imre Eilertsen (DandelionSprout)]

📖 Description

Added MSI Center.

✅ Checklist

• Signed the Contributor License Agreement
• Linked to an issue (if applicable)
  • Resolves #[Issue Number]

📦 Manifest Checklist

• Checked that there aren't other open pull requests for the same manifest update/change
• This PR only modifies one (1) manifest
• Validated manifest locally with winget validate --manifest <path> (validation guide)
• Tested manifest locally with winget install --manifest <path>
• Manifest conforms to the 1.12 schema

Note: <path> is the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

[wingetbot (wingetbot)]

Validation Pipeline Run WinGetSvc-Validation-148-407476-20260724-1

[wingetbot (wingetbot)]

Url Validation Error

• manifests/m/MSI/MSICenter/2.0.72
  • https://www.msi.com/Landing/MSI-Center
    • Http status code: Forbidden

[wingetbot (wingetbot)]

Validation Pipeline Run WinGetSvc-Validation-148-407476-20260724-2

[wingetbot (wingetbot)]

Validation Pipeline Run WinGetSvc-Validation-148-407476-20260724-3

[Imre Eilertsen (DandelionSprout)]

Photo of a display laptop at a hardware store that had MSI Center pre-installed on it:

Laptop:

[Kaleb Luedtke (Trenly)]

Because of the existence of PackageFamilyName, it implies the exe actually installs an MSIX package - And this does seem to be the case for the Installer URL.

However, the image you provided indicates that the install was done using an MSI.

AFAIK - AppsAndFeaturesEntries won't solve the issue of the two different install technologies. It's kind of like the old issue that PowerShell had where the version that came pre-installed with Windows was MSIX based but the packages from GitHub were msi based and users were very frustrated that they kept getting the message about An update is available but could not be installed because the install technologies are different.

I wonder if this would have the same issue?

[Imre Eilertsen (DandelionSprout)]

I remember from my tests that it was a complicated situation. The .exe indeed installs an MSIX package, which is apparently simply called "MSI Center". However, it also installs an MSI called "MSI Center SDK", but only on the first post-installation run of the MSIX.

In an attempt to make Winget detect the app, the plan was to rely on the ProductCode of that "MSI Center SDK". It's mere weeks ago that I began getting a grasp of how ProductCode worked like (after around 14 months), so I probably still don't have a perfect grasp of it.

[Imre Eilertsen (DandelionSprout)]

Trying to think closer in a hurry this morning to see if the "MSI Center SDK" factors could be cut entirely from this PR, which'd address the above worries, it would somehow just make it even less likely to detect existing installs. since the app's main Inno installer is seemingly just a bootstrap for the main UWP app.

[wingetbot (wingetbot)]

Validation Pipeline Run WinGetSvc-Validation-149-407476-20260802-1

[wingetbot (wingetbot)]

Publish pipeline succeeded for this Pull Request. Once you refresh your index, this change should be present.