packageManager.CreateCompositePackageCatalog(createOptions).Connect() returns CatalogError as status unless Microsoft.WindowsPackageManager.InProcCom >= 1.11.510

[BivinCBenny]

Relevant area(s)

COM API

Relevant command(s)

No response

Brief description of your issue

Calling: packageManager.CreateCompositePackageCatalog(createOptions).Connect();

returns CatalogError when using CompositeSearchBehavior.LocalCatalogs (or any other catalog), unless
the application references Microsoft.WindowsPackageManager.InProcCom version 1.11.510 or higher.

Noticed this behavior appearing in the last 2–3 weeks without any code changes in my projects.

Steps to reproduce

using Microsoft.Management.Deployment;

static void Main(string[] args)
{
var packageManager = new PackageManager();

var createOptions = new CreateCompositePackageCatalogOptions
{
    CompositeSearchBehavior = CompositeSearchBehavior.LocalCatalogs
};

var packageCatalogs = packageManager.GetPackageCatalogs();
foreach (var cat in packageCatalogs)
{
    createOptions.Catalogs.Add(cat);
}

var compositeConnectResult =
    packageManager.CreateCompositePackageCatalog(createOptions).Connect();

// compositeConnectResult.Status == CatalogError

var options = new FindPackagesOptions();
var result = compositeConnectResult.PackageCatalog.FindPackages(options);  // This throws null exception

}

Expected behavior

packageManager.CreateCompositePackageCatalog(createOptions).Connect() should:

Behave consistently across supported InProcCom versions and not randomly stop working in older versions.

Actual behavior

Connect() returns CatalogError in older versions

Environment

Windows 10 or Windows 11 device

[florelis]

This sounds like it may be due to the certificate pinning for the MS Store. When using the msstore source, winget checks the server certificate to make sure it is talking to the right server, but that breaks when the Store cert is renewed if winget doesn't know about the new one. I believe the Store updated their certificate within the last month.
There is an option in the CLI to skip the cert pinning check, but I don't think there is one in the COM API. Older versions of the API may still work if you skip adding the store catalog to the options.

[BivinCBenny]

@florelis Thanks for the explanation, as you said MS store source seems to be the issue when using a composite package.

To clarify expectations:

• Is this behavior expected for the COM API when the msstore catalog is included and the Store certificate rotates?
• Is there any plan to make Store certificate pinning more resilient on the WinGet side (e.g., via a live trust source), rather than requiring client updates when certificates rotate?
• Are there plans to expose a COM API equivalent of the CLI option that skips Store certificate pinning?
• Otherwise, should COM consumers treat excluding msstore as the recommended/long-term workaround?
• Also, what is the recommended long-term approach for COM consumers that need msstore support?

Just want to understand whether this is considered by design or a known limitation that may be improved.

[denelon]

@BivinCBenny we have been looking at mechanisms for making the client more resilient in terms of certificate rotation for the "msstore" source. It requires work from multiple teams, and not all of the sequencing has landed. We do update the WinGet client ahead of certificate changes, but not all devices are in a state where the client gets updated to the latest stable version which is often the case for a new/fresh Windows installation.

I'll let @JohnMcPMS respond to the recommended way of using the COM API.