Build SSMS extension VSIX in release workflow + bump to 1.11.1 (#343)#344
Merged
Conversation
The SSMS extension (PlanViewer.Ssms) is a legacy non-SDK project and is not part of PlanViewer.sln, so `dotnet build` never produced it. Releases shipped without the VSIX, leaving the README pointing at a stale v0.7.0 manual download while the extension was already at 1.11.0. - release.yml: build the VSIX via MSBuild + the installer via dotnet, and attach PlanViewer.Ssms.vsix + InstallSsmsExtension.exe to each release. continue-on-error keeps a VSIX build failure from blocking the cross-platform app release; warns on manifest/release version drift. - README.md: point SSMS install at the latest release. - McpHostService.cs: MCP server version was hardcoded at 0.7.0 - derive it from the assembly version so it tracks Directory.Build.props. - bug_report.yml: refresh the version placeholder. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
erikdarlingdata
changed the title
2 tasks
erikdarlingdata
added a commit
that referenced
this pull request
May 22, 2026
The v1.11.1 release attempt exposed two bugs in the VSIX step added in #344: 1. The "Warn if SSMS extension build failed" step had `(issue #343)` in a single-line `run:` value. YAML treated ` #343)"` as a comment, leaving pwsh an unterminated string. The step failed, and because it was not continue-on-error it failed the whole job - skipping signing, Velopack, and every artifact upload. v1.11.1 was created empty and has been deleted. 2. The VSIX build itself failed: `msbuild -t:Restore,Build` evaluates the project once before Restore writes the package-generated props, so VSToolsPath never got redirected into the Microsoft.VSSDK.BuildTools package and the VSSDK targets could not be found (MSB4226). Fixes: - Build the VSIX with `msbuild -restore -t:Build` so Restore runs in its own evaluation and the VSSDK targets resolve without the VS workload. - Remove the separate warn step. The build step now only sets a `BUILT` output on success and the upload is gated on it - nothing in the SSMS path can fail the job anymore. - Drop non-ASCII characters from the run-block strings. - Bump version to 1.11.2 (1.11.1 is burned). Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Addresses #343 — the SSMS extension had limited discoverability because it was never built by the release workflow.
Problem
PlanViewer.Ssmsis a legacy non-SDK project and is not part ofPlanViewer.sln, sodotnet buildnever produced it. Releases shipped without the VSIX — the README still pointed users at a manual download from the v0.7.0 release while the extension manifest was already at 1.11.0.Changes
release.yml— build the VSIX via MSBuild and the installer viadotnet, then attachPlanViewer.Ssms.vsix+InstallSsmsExtension.exeto each release.continue-on-errorkeeps a VSIX build failure from blocking the cross-platform app release; warns if the vsixmanifest version drifts from the release version.README.md— SSMS install link now points at the latest release.McpHostService.cs— MCP server version was hardcoded at0.7.0; now derived from the assembly version so it tracksDirectory.Build.props.bug_report.yml— refresh the version placeholder.Test plan
PlanViewer.Ssms.vsix(the VSIX build in CI may need one iteration —continue-on-errordegrades gracefully if the runner lacks VSSDK targets).dotnet build src/PlanViewer.Appsucceeds locally (0 errors).Follow-ups (not in this PR)
🤖 Generated with Claude Code