Problem
scripts/download-cli.ps1 defaults to downloading the latest winappcli release, but the extension's command surface is written against a specific CLI version. Today that means the extension ships a 0.6.x CLI behind a UI designed for ~0.3.1 — the version skew is invisible and unbounded in both directions.
The reverse direction is the dangerous one: as we add flags for newer CLI features, an extension build paired with an older CLI will emit flags that don't exist and fail at runtime with a raw CLI parse error.
Why it matters now
The winapp run project-mode work adds --project, --configuration, --arch, --framework, --runtime, --property, --no-build, and --no-restore — all of which are 0.6.x-only. If a user's bundled CLI predates them, project mode fails with an unhelpful error and no indication that a version mismatch is the cause.
Options
- Pin the tag in
download-cli.ps1 to the version the extension was developed and tested against, and bump it deliberately alongside UI changes. npm run download-cli:latest stays available for local testing.
- Probe
winapp --version once at activation and degrade the UI (hide project-mode entries, disable new options) when the CLI is older than required — more forgiving for users who point the extension at their own CLI build, but more machinery.
- Possibly both: pin for the shipped default, probe as a safety net.
Acceptance
Either the bundled CLI version is deterministic for a given extension version, or the extension detects a too-old CLI and reports it as a version mismatch rather than surfacing a raw argument-parsing failure.
Problem
scripts/download-cli.ps1defaults to downloading thelatestwinappcli release, but the extension's command surface is written against a specific CLI version. Today that means the extension ships a 0.6.x CLI behind a UI designed for ~0.3.1 — the version skew is invisible and unbounded in both directions.The reverse direction is the dangerous one: as we add flags for newer CLI features, an extension build paired with an older CLI will emit flags that don't exist and fail at runtime with a raw CLI parse error.
Why it matters now
The
winapp runproject-mode work adds--project,--configuration,--arch,--framework,--runtime,--property,--no-build, and--no-restore— all of which are 0.6.x-only. If a user's bundled CLI predates them, project mode fails with an unhelpful error and no indication that a version mismatch is the cause.Options
download-cli.ps1to the version the extension was developed and tested against, and bump it deliberately alongside UI changes.npm run download-cli:lateststays available for local testing.winapp --versiononce at activation and degrade the UI (hide project-mode entries, disable new options) when the CLI is older than required — more forgiving for users who point the extension at their own CLI build, but more machinery.Acceptance
Either the bundled CLI version is deterministic for a given extension version, or the extension detects a too-old CLI and reports it as a version mismatch rather than surfacing a raw argument-parsing failure.