Skip to content

Add IsReinstallAvailable and ReinstallRequiredReason to CatalogPackage #6143

@DenWin

Description

@DenWin

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area-COM-APIIssue related to COM APIIssue-FeatureThis is a feature request for the Windows Package Manager client.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions