Add IsReinstallAvailable and ReinstallRequiredReason to CatalogPackage

Relevant area(s)

COM API

Description of the new feature / enhancement

CatalogPackage currently exposes IsUpdateAvailable, which only indicates whether a newer version has an applicable in-place update path.

Please add support to identify reinstall-required updates, where a newer version exists but cannot be upgraded in place and instead requires uninstall + reinstall. A typical example is installer technology mismatch.

This would let API consumers distinguish between:

1. No newer version exists
2. A newer version exists and is updateable
3. A newer version exists but is reinstall-required

Without this distinction, API consumers cannot reliably guide users toward the correct remediation path.

Proposed technical implementation details

Add two new properties to CatalogPackage:

1. IsReinstallAvailable (Boolean)
2. ReinstallRequiredReason (enum)

Keep IsUpdateAvailable semantics unchanged.

Suggested enum values

1. None
2. InstallerTechnologyMismatch
3. InstalledTypeMismatch
4. InstalledScopeMismatch
5. Other

Expected behavior

1. Applicable update exists

   • IsUpdateAvailable = true
   • IsReinstallAvailable = false
   • ReinstallRequiredReason = None

2. Newer version exists, but in-place update is blocked by installer technology mismatch

   • IsUpdateAvailable = false
   • IsReinstallAvailable = true
   • ReinstallRequiredReason = InstallerTechnologyMismatch

3. Newer version exists, but is blocked by non-reinstall constraints
   For example: OS version, architecture, market, or other general applicability constraints.

   • IsUpdateAvailable = false
   • IsReinstallAvailable = false
   • ReinstallRequiredReason = Other (or None, depending on final API design)

4. No newer version exists

   • IsUpdateAvailable = false
   • IsReinstallAvailable = false
   • ReinstallRequiredReason = None

Suggested implementation approach

The relevant implementation path appears to be:

RepositoryCore applicability selection
-> COM projection
-> CatalogPackage properties

Concrete areas:

• Extend the result returned by repository-side version selection so it can carry:
  • latest applicable version
  • update availability
  • reinstall availability
  • reinstall reason
• Reuse existing installer applicability analysis and mismatch classification already used during upgrade selection.

Potential implementation points:

• src/AppInstallerRepositoryCore/Public/winget/PackageVersionSelection.h
• src/AppInstallerRepositoryCore/PackageVersionSelection.cpp
• src/AppInstallerCommonCore/Public/winget/ManifestComparator.h
• src/Microsoft.Management.Deployment/PackageManager.idl
• src/Microsoft.Management.Deployment/CatalogPackage.h
• src/Microsoft.Management.Deployment/CatalogPackage.cpp

Compatibility requirements

• Do not change existing IsUpdateAvailable behavior.
• Add new properties in a backward-compatible COM contract version.
• Preserve existing callers that only understand update vs no-update.

Acceptance criteria

1. Existing IsUpdateAvailable behavior remains backward compatible.
2. Reinstall-required scenarios are reported deterministically.
3. The reason enum is documented and stable.
4. API contract versioning remains backward compatible.
5. Tests cover:
   • update available
   • reinstall available
   • neither available

Start with src/AppInstallerRepositoryCore/Public/winget/PackageVersionSelection.h and PackageVersionSelection.cpp to trace applicability selection, then follow the COM projection in CatalogPackage.h, CatalogPackage.cpp, and PackageManager.idl. Review ManifestComparator.h for existing mismatch classification and the contract-versioning requirements. Done means deterministic update/reinstall states, a documented stable reason enum, backward-compatible IsUpdateAvailable behavior, and tests for update, reinstall, and neither available.