Fix SSMS VSIX release step + bump to 1.11.2 (#343)

[erikdarlingdata]

Fixes the SSMS VSIX release step from #344. The v1.11.1 release attempt was the test that exposed both bugs.

What went wrong with v1.11.1

1. YAML comment ate part of a command. The Warn if SSMS extension build failed step had (issue #343) in a single-line run: value. YAML treats # as the start of a comment, so the command became an unterminated pwsh string and the step failed. That step was not continue-on-error, so it failed the whole release job — skipping signing, Velopack, and every artifact upload. v1.11.1 was created empty and has since been deleted (release + tag).

2. The VSIX build genuinely failed with MSB4226: ...Microsoft.VsSDK.targets was not found. msbuild -t:Restore,Build evaluates the project once before Restore writes the package-generated props, so VSToolsPath was never redirected into the Microsoft.VSSDK.BuildTools package — the runner has no VS extension-development workload, so the VSSDK targets were unreachable.

Fixes

• Build with msbuild -restore -t:Build — Restore runs in its own evaluation, so the Microsoft.VSSDK.BuildTools package props are in place before Build and the VSSDK targets resolve without the VS workload.
• Removed the separate warn step. The build step now only sets a BUILT output on success; the upload is gated on it. Nothing in the SSMS path can fail the release job anymore — worst case is a release without the VSIX plus a CI warning.
• Dropped non-ASCII characters from the run:-block strings.
• Bump to 1.11.2 (1.11.1 is burned).

Test plan

• CI build/test green.
• After this merges to main, the v1.11.2 release run should attach PlanViewer.Ssms.vsix + InstallSsmsExtension.exe and complete signing/Velopack/zip uploads. The -restore fix for the VSIX is a strong diagnosis but is verified only by that run; if it still fails, the release now completes cleanly without the VSIX instead of breaking.

🤖 Generated with Claude Code