Surface reinstall-required availability in WinGet CLI, PowerShell Module, and DSC Resource

Relevant area(s)

WinGet CLI, PowerShell Module, DSC Resource

Description of the new feature / enhancement

After API support exists for IsReinstallAvailable and ReinstallRequiredReason, surface this information in user-facing tools and automation surfaces.

Without surfacing, users and scripts still cannot reliably act on reinstall-required updates.

This would improve:

1. CLI guidance when a normal update is not possible
2. PowerShell automation that needs to branch between update and reinstall
3. DSC compliance/reporting for packages where the latest version requires reinstall

Proposed technical implementation details

This issue depends on the API/core feature that introduces:

• IsReinstallAvailable
• ReinstallRequiredReason

Requested client surfacing

WinGet CLI

Surface clear and actionable messaging when:

• a newer version exists
• IsUpdateAvailable is false
• IsReinstallAvailable is true

Examples of possible UX:

• Show a message during upgrade discovery
• Show a message in package detail views
• Optionally distinguish this state in upgrade-listing output

PowerShell Module

Expose the new properties in projected package objects so scripts can evaluate:

$pkg.IsUpdateAvailable
$pkg.IsReinstallAvailable
$pkg.ReinstallRequiredReason

If appropriate, also surface the new state in formatting/output.

DSC Resource

Use reinstall-required metadata in detection and reporting logic so DSC can distinguish:

1. package is compliant
2. package can be updated in place
3. package requires reinstall to reach the newer version

Potential implementation areas

• DscPackageResource.cpp
• UpdateFlow.cpp
• PSCatalogPackage.cs
• src/PowerShell/Microsoft.WinGet.Client/Format.ps1xml
• Microsoft.WinGet.DSC.psm1

Suggested rollout

1. Land the COM API/core feature first
2. Update PowerShell and DSC consumers next
3. Add or refine CLI UX after that if separate review is preferred

Acceptance criteria

1. CLI clearly communicates reinstall-required status.
2. PowerShell exposes both new properties for scripting.
3. DSC can distinguish updateable state from reinstall-required state.
4. Tests cover at least one installer technology mismatch scenario.

Start with the dependent COM API/core work in issue 6143, then inspect DscPackageResource.cpp, UpdateFlow.cpp, PSCatalogPackage.cs, Format.ps1xml, and Microsoft.WinGet.DSC.psm1. Trace how package update state is surfaced in each client and identify existing tests for installer technology mismatches. Done means the CLI, PowerShell, and DSC surfaces distinguish reinstall-required packages and the acceptance criteria are covered.