Skip to content

Move the package versions to central package management - #56

Open
xperiandri wants to merge 14 commits into
mrlacey:mainfrom
xperiandri:chain/central-packages
Open

xperiandri wants to merge 14 commits into
mrlacey:mainfrom
xperiandri:chain/central-packages

Conversation

@xperiandri

@xperiandri xperiandri commented Oct 27, 2026 •

Copy link
Copy Markdown

Summary

Stacked on #55. The branch contains the commits of #55 and of the pull requests before it, so the last 2 commits are new here.

This pull request moves the package versions of both projects into Directory.Packages.props (central package management). It requires #55 (the edit is made on the SDK-style projects). The new commits are Move the package versions to central package management and Update the instructions for central package management; the extension code does not change.

Chain, changes, things to know and verification

Chain

This pull request is part of a chain of small pull requests that are stacked on each other. The branch of each one contains the commits of the earlier ones, so GitHub lists those commits here until the earlier pull requests are merged. All of them target main. Merge them in this order and review only the commits that are new in each pull request:

  1. Switch the solution to the .slnx format #53 – Switch the solution to the .slnx format (first in the chain, no dependencies)
  2. Add instructions, skills and MCP configuration for AI coding agents #54 – Add instructions, skills and MCP configuration for AI coding agents (stacked on Switch the solution to the .slnx format #53)
  3. Convert the projects to the SDK style #55 – Convert the projects to the SDK style (stacked on Add instructions, skills and MCP configuration for AI coding agents #54)
  4. Move the package versions to central package management #56 – Move the package versions to central package management (stacked on Convert the projects to the SDK style #55) – this pull request
  5. Set the C# language version to 14 #57 – Set the C# language version to 14 (stacked on Move the package versions to central package management #56)
  6. Build with dotnet build #58 – Build with dotnet build (stacked on Set the C# language version to 14 #57)

Changes

  • Directory.Packages.props holds one PackageVersion for each of the 19 packages, in three groups: the packages of the extension, the dependencies that the projects name explicitly, and the test packages. The two projects name the packages only. The versions are the ones the projects had; where both projects used a package they used the same version, so one entry replaces two.
  • The file is added to the solution items, and the instructions say where the versions are.

Things to know

  • A version is changed in one place now, and a project can still deviate with VersionOverride. Central package management needs NuGet 6.2 or later, which the build tools of this repository have.
  • nuget.config (the package source mapping) is unchanged.

Verification

  • The resolved packages are the same: project.assets.json lists the same 154 libraries for the extension and the same 162 for the tests, with the same entries for net481. In Debug and Release the references, the 26 distinct warnings, the VSIX entries and the fingerprints of both assemblies are identical to the previous commit, and the 4 tests pass (the MSBuild of Visual Studio 2026 18.12).
  • The workflows of this repository wait for the approval of a maintainer on a pull request, so the commit ran in a fork. Build builds, tests and uploads a VSIX with the same 34 entries and sizes as the run for the previous pull request, and Copilot Setup Steps passes. The step Publish Test Results then fails, because the third-party action EnricoMi/publish-unit-test-result-action/windows@v2 finds no Python interpreter on the image (No python3 interpreter found); it fails in the same way on the unchanged code of main (run in the fork), so it is not caused by this change and not fixed here.

🤖 Generated with Claude Code

xperiandri and others added 14 commits October 27, 2026 02:21
`dotnet sln migrate` produced `StringResourceVisualizer.slnx` from `StringResourceVisualizer.sln`, and the old file is removed. The projects and the solution items are the same. The project ids are the ones of the old solution, which is what Visual Studio writes into the file itself. The `.slnx` format is XML, much shorter than the `.sln`, and designed to reduce merge conflicts (https://devblogs.microsoft.com/visualstudio/new-simpler-solution-file-format/).

Building it needs the .NET SDK 9.0.200 or later, or MSBuild from Visual Studio or Build Tools 17.13 or later.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
`.github/copilot-instructions.md` is the single source for GitHub Copilot, Claude Code and other agents: the build and test commands, the structure, how the adornments work, the parts that belong to the original author, the rules for Visual Studio extensions and the C# guidelines. `CLAUDE.md` imports it and `AGENTS.md` points to it.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
`create-pr-description.prompt.md` compares the branch with `origin/main` and fills in the pull request template. This repository has no template, so the prompt falls back to a default structure.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A custom agent for the extension code, based on `madskristensen/CustomAgents`. It refers to the project instructions and to the skills instead of repeating them.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Six skills of `madskristensen/vs-agent-plugins` (commit e971073e2163d4bc66d3e455e102c316e01c94c6) that apply to this extension: `handling-async-threading`, `handling-extension-errors`, `adding-editor-adornments`, `listening-text-view-events`, `adding-options-settings` and `handling-solution-events`. The content is unchanged. The Apache License 2.0 of the upstream repository comes with them, and `README.md` names the source.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Git cannot store a Windows junction, so `Directory.Build.targets` creates it when Visual Studio loads the project, and `.gitignore` excludes it. A command-line build skips the target. `Directory.Build.targets` is a solution item.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
`.claude/settings.json` registers the `vs-agent-plugins` marketplace and enables `vs-extensibility-skills`, the whole catalogue of 40 skills. If Claude Code does not offer to install it, `claude plugin install vs-extensibility-skills@vs-agent-plugins --scope project` does.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The job runs on `windows-2022`: the VSIX builds only with the MSBuild of Visual Studio, and the extension targets Visual Studio 2022. The integrated firewall of the agent is not compatible with Windows, so the agent runs without it.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
`.mcp.json` lists `GitHub` for Visual Studio and Claude Code, and `Microsoft Learn` for Claude Code only, because Visual Studio bundles that server itself.

The GitHub server does not support the OAuth dynamic client registration that Claude Code needs, so `.claude/scripts/github-mcp-headers.ps1` passes it the token that Git Credential Manager already stores. `.mcp.json` is a solution item.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Both projects use `Microsoft.NET.Sdk` with `net481` now, and `VSSDKBuildToolsAutoSetup` with `Microsoft.VSSDK.BuildTools` 18.5 builds the VSIX. The source files are included by globbing; the extension project excludes the folder of the test project, which lies inside its own folder. `Properties\AssemblyInfo.cs` stays, because the version comes from the `Vsix` constants, and the output stays in `bin\Debug\` and `bin\Release\`.

The signing target is called `SignAndCopyVsix` and runs after `Build`. As `AfterBuild` it would be replaced by the SDK targets and never run.

The packages and their versions are the same, apart from the added `Microsoft.VSSDK.BuildTools`.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Visual Studio 2026 18.5 and later deploys an SDK-style VSIX project to the Experimental instance on F5 only when the solution has a `<Deploy>` element for it.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
New files need no entry in the project any more, only a file that goes into the VSIX needs a `Content` item. The .NET Framework 4.8.1 targeting pack is not needed, the signing target has a new name, and F5 needs Visual Studio 2026 18.5 or later.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
`Directory.Packages.props` holds the version of each of the 19 packages, and the two projects name the packages only. The versions are the ones the projects had, so the resolved packages (154 for the extension, 162 for the tests) are the same as before.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
The package versions are in `Directory.Packages.props` now.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant