Case-folding of "ProductCode" field

[denelon]

Brief description of your issue

The client calls a REST source and passes in the productCode in lowercase. It's doing "Exact" matching when it probably should be doing "caseInsesnsitive" as referenced in:

• case-folding of "ProductCode" field winget-cli-restsource#166

Steps to reproduce

Add a manifest with a product code containing an upper case productCode to the REST source.
Attempt to get a matching result with the client.

Expected behavior

A match is returned

Actual behavior

No match is returned.

Environment

winget --info                                                                   in pwsh at 10:54:42
Windows Package Manager (Preview) v1.4.2161-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.25212.1000
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.2161.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Group Policy                               State
---------------------------------------------------
Enable Windows App Installer Hash Override Disabled

[jantari]

I can't read C++ but in the spirit of Hacktoberfest I tried to look into this. I've found what I think are two possible sources of this problem, depending on what is called by what when:

First, this comment and code in WorkflowBase.cpp seems to imply ProductCodes are intentionally always searched "Exact":

winget-cli/src/AppInstallerCLICore/Workflows/WorkflowBase.cpp

Lines 472 to 477 in 8d0996f

	// Regardless of match type, always use an exact match for the system reference strings.
	searchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::PackageFamilyName, MatchType::Exact, query));
	searchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::ProductCode, MatchType::Exact, query));
	searchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::Id, matchType, query));
	searchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::Name, matchType, query));
	searchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::Moniker, matchType, query));

and then further down the same file we have some more interesting logic that always searches for ProductCodes with MatchType "Exact", but does make an exception for portable packages specifically and treats those correctly with CaseInsensitive:

winget-cli/src/AppInstallerCLICore/Workflows/WorkflowBase.cpp

Lines 1073 to 1081 in 8d0996f

	else if (!installer.ProductCode.empty())
	{
	searchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::ProductCode, MatchType::Exact, installer.ProductCode));
	}
	else if (installer.EffectiveInstallerType() == Manifest::InstallerTypeEnum::Portable)
	{
	const auto& productCode = Utility::MakeSuitablePathPart(manifest.Id + "_" + source.GetIdentifier());
	searchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::ProductCode, MatchType::CaseInsensitive, Utility::Normalize(productCode)));
	}

Then there's also some sussy stuff in ARPCorrelation.cpp, but to me it reads like these searches are only comparing the current ARP state to a cached/prior ARP state so maybe this code doesn't actually interact with a remote source:

winget-cli/src/AppInstallerRepositoryCore/ARPCorrelation.cpp

Lines 193 to 223 in 8d0996f

	for (const auto& installer : manifest.Installers)
	{
	if (!installer.ProductCode.empty())
	{
	// Add each ProductCode only once
	if (productCodes.insert(installer.ProductCode).second)
	{
	manifestSearchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::ProductCode, MatchType::Exact, installer.ProductCode));
	}
	}
	for (const auto& appsAndFeaturesEntry : installer.AppsAndFeaturesEntries)
	{
	if (!appsAndFeaturesEntry.DisplayName.empty())
	{
	manifestSearchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::NormalizedNameAndPublisher, MatchType::Exact,
	appsAndFeaturesEntry.DisplayName,
	appsAndFeaturesEntry.Publisher.empty() ? defaultPublisher : appsAndFeaturesEntry.Publisher));
	}
	// Add each ProductCode and UpgradeCode only once;
	if (!appsAndFeaturesEntry.ProductCode.empty() && upgradeCodes.insert(appsAndFeaturesEntry.ProductCode).second)
	{
	manifestSearchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::ProductCode, MatchType::Exact, appsAndFeaturesEntry.ProductCode));
	}
	if (!appsAndFeaturesEntry.UpgradeCode.empty() && upgradeCodes.insert(appsAndFeaturesEntry.UpgradeCode).second)
	{
	manifestSearchRequest.Inclusions.emplace_back(PackageMatchFilter(PackageMatchField::UpgradeCode, MatchType::Exact, appsAndFeaturesEntry.UpgradeCode));
	}
	}
	}

If the issue really is in WorkflowBase.cpp where I pointed to I could open a PR, but my C++ skills won't go much beyond replacing MatchType::Exact with MatchType::CaseInsensitive so if there's a lot of other impacted or related code, or special exceptions would have to be made I couldn't do that.

[denelon]

@ryfu-msft the origin of this came from winget-cli-restsource. Does this look like it's sufficient, or would more work be involved (test cases impacted)?

[jantari]

Is there an update on this?