feat(open): add 'open vscode' and 'open ssms', remove retired 'open ads'#688
Open
dlevy-msft-sql wants to merge 36 commits into
Open
feat(open): add 'open vscode' and 'open ssms', remove retired 'open ads'#688dlevy-msft-sql wants to merge 36 commits into
dlevy-msft-sql wants to merge 36 commits into
Conversation
dlevy-msft-sql
added
Size: S
There was a problem hiding this comment.
Pull request overview
This PR adds support for opening Visual Studio Code and SQL Server Management Studio (SSMS) to work with SQL Server connections managed by sqlcmd, addressing the deprecation of Azure Data Studio. The implementation uses clipboard-based password sharing since both tools use sandboxed credential storage.
Changes:
- Adds
sqlcmd open vscodecommand that creates connection profiles in VS Code settings and auto-installs the MSSQL extension - Adds
sqlcmd open ssmscommand (Windows-only) that launches SSMS with pre-configured connection parameters - Implements cross-platform clipboard support for secure password sharing
- Includes comprehensive tests and documentation updates
Reviewed changes
Copilot reviewed 30 out of 31 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
cmd/modern/root/open.go |
Updates open command to include VSCode and SSMS subcommands |
cmd/modern/root/open/vscode.go |
Main VSCode command implementation with settings file manipulation |
cmd/modern/root/open/vscode_*.go |
Platform-specific VSCode implementations |
cmd/modern/root/open/ssms.go |
Main SSMS command implementation |
cmd/modern/root/open/ssms_*.go |
Platform-specific SSMS implementations (Fatal on non-Windows) |
cmd/modern/root/open/clipboard.go |
Helper function for clipboard-based password sharing |
cmd/modern/root/open/*_test.go |
Comprehensive test coverage for new commands |
internal/tools/tool/vscode*.go |
VSCode tool detection and configuration |
internal/tools/tool/ssms*.go |
SSMS tool detection and configuration |
internal/pal/clipboard*.go |
Cross-platform clipboard implementation using native APIs |
internal/tools/tools.go |
Registers VSCode and SSMS tools |
README.md |
Adds clear documentation with usage examples |
.gitignore |
Adds /modern build artifact |
…ectory exec.Cmd.Start on the .app directory fails with permission denied. Probe the PATH shim first, then fall back to <app>/Contents/Resources/app/bin/code at the standard install locations.
os/exec.Cmd elements are not shell-parsed, so strings.ReplaceAll of double quotes injected literal backslashes into the SSMS login dialog. Drop the escape and let SSMS see the username verbatim.
readSettings strips JSONC features so the standard json package can parse it, but writeSettings then round-trips through encoding/json and silently drops the user's comments. Detect the JSONC features on read, save the original to settings.json.sqlcmd-backup, and warn so the user can restore anything they care about.
RunWithOutput on tool.VSCode is a test-only stub with no callers since isMssqlExtensionInstalled started reading the extensions directory directly. Delete it. Remove tests that re-implement production logic inside the test file (buildServerArg, username ReplaceAll) or set config values and read them back, plus the clipboard test that t.Logf's its error and asserts nothing.
Previous commit 9c97b72 pointed searchLocations at <bundle>/Contents/Resources/app/bin/code, but tool_darwin.go's generateCommandLine launches via 'open -a <path> --args ...', which only accepts registered app names or .app bundle paths. With the changed location, open -a fails with 'Unable to find application'. file.Exists already accepts directories, so the original .app path was correct end-to-end. Restore it and keep the additional \C:\Users\DLevy/Applications probe.
… fire-and-forget it tool.Run calls Process.Release immediately after Start, so the previous 'MSSQL extension installed successfully' message printed before the install had a chance to fail. Tell the user the install was requested and to watch VS Code for progress; only warn when the launch itself fails.
…ner leak
When os.OpenFile(os.DevNull) fails, the original code fell through with the bytes.Buffer pipes generateCommandLine attached, which makes exec.Cmd.Start spawn drainer goroutines that block on the GUI tool's stdout/stderr until it exits, defeating the Process.Release detach. Set Std{in,out,err} to nil in the fallback so the child inherits the parent's stdio with no extra goroutines.
The Windows assertion strings.Contains(stable, "Code") was structurally always-true because the build name itself was "Code". Assert the full AppData/Roaming/Code/User/settings.json tail on Windows, the Library/Application Support/... tail on macOS, and the .config/... tail on Linux so the test would actually catch a wrong configDir.
When VS Code follows the vscode://ms-mssql.mssql/connect URL and the mssql extension is not installed, VS Code itself prompts the user to install it. That UX is strictly better than the fire-and-forget `code --install-extension` shell-out, which could not report success or failure (tool.Run calls Process.Release immediately after Start). Removes the --install-extension flag, the installExtension field, the pre-launch isMssqlExtensionInstalled directory scan, and the related example/messaging. The flag was added earlier in this PR and never shipped, so this is not a user-visible breaking change. Also regenerates the translations catalog to drop the corresponding strings.
- README: rewrite vscode section; remove --install-extension flag step and clipboard step (URL handler now triggers extension install prompt) - vscode_windows installText: replace --install-extension instructions with URL-handler note - pal/clipboard_linux: use fmt.Errorf instead of localizer.Errorf (gotext scope excludes internal/pal)
…ion hint RunWithOutput had no callers and could mislead on Start failures (exitCode 0 when ProcessState is nil). Remove the method and its interface entry. Update vscode_linux/vscode_darwin install text to match windows: extension installs on first use via the vscode:// URL handler, no --install-extension flag.
The rebase onto upstream/main resolved internal/translations/* using -X theirs, which took upstream's catalog.go. That catalog's placeholder bindings no longer match this branch's source strings, causing TestSqlCmdOutputAndError to emit 'Invalid variable identifier $!(UNKNOWNMSGHANDLER=0x61)' instead of the expected error. Restore internal/translations/ to the pre-rebase state from this branch so generated bindings match the source.
dlevy-msft-sql
commented
May 29, 2026
The MSSQL extension expects the connection profile server field in 'host,port' grammar (matching .devcontainer/devcontainer.json), not the 'tcp:host,port' form sqlcmd/go-mssqldb uses. Prefixing with 'tcp:' prevented the extension from matching the saved profile when launched via the vscode://ms-mssql.mssql/connect URI. Drop the prefix in both createProfile and mssqlConnectURI. Also fix TestVSCodeCreateProfile, which stored the password as plain text. config.GetCurrentContextInfo() runs the stored value through secret.Decode, so the test panicked once createProfile started reading the password. Encode with secret.Encode and set PasswordEncryption='none' to match.
Address PR microsoft#688 review feedback: - Add 'sqlcmd open vscode' to root help example chain (was Windows-only via ssms). - In 'sqlcmd config add-context' next-step hints, include 'Open in SQL Server Management Studio' only on Windows; always include 'Open in Visual Studio Code'. - Match ssms Short text on Windows and non-Windows builds; both now say '(Windows only)' so users on macOS/Linux understand why 'sqlcmd open ssms --help' shows up alongside vscode. - Remove /modern from .gitignore. No build path produces a 'modern' binary at the repo root; the rule was dead.
Add TestSSMSNotInstalledWhenSsmsExeMissing: when vswhere reports an install root but Common7\IDE\Ssms.exe is absent (corrupt install, or another VS product registered under the same productID), IsInstalled must return false. This was the only gap in ssms_windows_test.go alongside the existing Windows-only coverage in vswhere_windows_test.go (version range pinning, latest fallback, multi-line output, exec failure, missing vswhere.exe). Delete the cross-platform ssms_test.go. Its sole assertion was that Name() returns 'ssms', which is set by a literal string in Init() and tests nothing about the SSMS discovery or launch behavior that actually matters.
dlevy-msft-sql
added a commit
to dlevy-msft-sql/go-sqlcmd
that referenced
this pull request
May 29, 2026
Replace the strip-comments-then-marshal round trip (which silently lost user comments and trailing commas, requiring a .sqlcmd-backup file written alongside settings.json) with a hujson AST patch. We parse the original document, build an RFC 6902 patch that adds or replaces only the two keys we own (mssql.connections, mssql.connectionGroups), and pack the modified AST. Comments, trailing commas, and unrelated user settings round-trip untouched on replace operations. Drops the multi-backup hazard raised in PR microsoft#688: the previous code overwrote settings.json.sqlcmd-backup on every invocation, so a second container creation lost the original. With comments preserved, no backup file is created. Full AST-level preservation across additions and per-connection comments is tracked in microsoft#767.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 60 out of 72 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
internal/tools/tool/tool_test.go:107
- TestRun starts an interactive shell (cmd.exe) with arbitrary args and tool.Run now detaches the process, so on Windows this can leave a stray cmd.exe running (and on non-Windows COMSPEC is typically unset). Make the test run an OS-appropriate command that exits immediately (e.g.,
cmd.exe /c exit 0or/bin/sh -c true) so the test is deterministic and doesn’t spawn long-lived processes.
Replace the strip-comments-then-marshal round trip (which silently lost user comments and trailing commas, requiring a .sqlcmd-backup file written alongside settings.json) with a hujson AST patch. We parse the original document, build an RFC 6902 patch that adds or replaces only the two keys we own (mssql.connections, mssql.connectionGroups), and pack the modified AST. Comments, trailing commas, and unrelated user settings round-trip untouched on replace operations. Drops the multi-backup hazard raised in PR microsoft#688: the previous code overwrote settings.json.sqlcmd-backup on every invocation, so a second container creation lost the original. With comments preserved, no backup file is created. Full AST-level preservation across additions and per-connection comments is tracked in microsoft#767.
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
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.
Summary
Adds two new subcommands and removes one that no longer applies:
sqlcmd open vscode— writes a connection profile for the current context into VS Code'ssettings.jsonand launches VS Code on it via thevscode://URL handler (which prompts to install the MSSQL extension on first use if needed).sqlcmd open ssms— launches SSMS connected to the current context (Ssms.exe -S host,port -nosplash [-C] [-U user]with the password handed off via the clipboard).sqlcmd open adsis removed: Azure Data Studio was retired in August 2025.Password handling for VS Code
The VS Code profile includes the SQL password inline in
settings.jsonrather than prompting the user for it.sqlcmd's containers are short-lived local development instances with throwaway credentials, and the goal ofopen vscodeis one-shot, zero-prompt connect. The MSSQL extension migrates the password out ofsettings.jsonand into the OS credential store on first read, so the on-disk window is brief; we accept that trade-off in exchange for not requiring the user to paste a password they did not choose. This applies only to the local-container dev flow; users connecting to real servers should manage credentials through the extension directly.Editor discovery (Windows)
PATH(code/code-insiders) → Inno Setup uninstall registry → default install dirs.--build stable|insidersselects which build to launch; the connection profile is written to that build'ssettings.jsonso the profile and the launched build always match.vswhere -products Microsoft.VisualStudio.Product.Ssms, which finds SSMS 21+ on any drive.--versionpins a major version; values below 21 are rejected (older SSMS releases are legacy-MSI and aren't registered with the VS Installer).Why not
ssms://?An earlier revision used the
ssms://protocol handler. Its grammar only acceptss/a/u/d/h/q/dnand silently drops-C(trust server certificate) and-P. Local container connections need-C, so the URL path could not connect to a fresh local SQL container regardless of SSMS version. That commit was reverted; the argv launch path is what ships.Testing
go build ./...on windows/linux/darwingo test ./internal/tools/tool/... ./cmd/modern/root/open/...settings.jsonrouting.