Skip to content

Switch the solution to the .slnx format - #53

Open
xperiandri wants to merge 1 commit into
mrlacey:mainfrom
xperiandri:chain/slnx
Open

xperiandri wants to merge 1 commit into
mrlacey:mainfrom
xperiandri:chain/slnx

Conversation

@xperiandri

@xperiandri xperiandri commented Oct 27, 2026 •

Copy link
Copy Markdown

Summary

This pull request converts the solution from StringResourceVisualizer.sln to StringResourceVisualizer.slnx, the XML solution format. It is the first pull request of a chain of small ones that modernize the build of the repository. The only new commit is Switch the solution to the .slnx format; the extension code and the project files do not change.

Chain, changes, things to know and verification

Chain

This pull request is part of a chain of small pull requests that all target main. After #53 the chain has two branches that do not depend on each other: the AI agent files (#54) and the modernization of the build (#55 to #58). The last pull request (#69) merges both and updates the instructions, which live in the files of the AI branch. The branch of each pull request contains the commits of the ones it is stacked on, so GitHub lists those commits here until they are merged. Merge 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) – this pull request
  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 Switch the solution to the .slnx format #53)
  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)
  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)
  7. Update the instructions for the SDK-style projects, central package management, C# 14 and dotnet build #69 – Update the instructions for the SDK-style projects, central package management, C# 14 and dotnet build (stacked on Build with dotnet build #58 and Add instructions, skills and MCP configuration for AI coding agents #54)

Changes

  • StringResourceVisualizer.slnx replaces StringResourceVisualizer.sln. dotnet sln migrate produced it; the two projects and the solution items (.editorconfig, CHANGELOG.md and README.md) are the same, and the project ids are the ones of the old solution (Visual Studio adds them to a .slnx anyway). The file has 9 lines instead of 38.
  • Nothing else changes: build.yaml runs msbuild in the repository root without naming a solution, and the MSBuild of the windows-2022 image finds the .slnx by itself.

Things to know

  • The format is XML, short, easy to read and edit, and designed to reduce merge conflicts; dotnet new sln creates it by default since .NET 10.
  • The price is the tooling: a .slnx needs the .NET SDK 9.0.200 or later, or MSBuild from Visual Studio or Build Tools 17.13 or later (the minimum that Microsoft states). A Visual Studio 2022 older than 17.13 cannot open the solution, and nuget restore cannot restore it (msbuild -restore and dotnet restore can, and the workflow uses msbuild -restore). The extension supports Visual Studio 2022 from 17.10, so whether to require 17.13 of the contributors is a decision for the maintainer.
  • Related, but independent: Watch .slnx solution files as well as .sln #51 teaches the extension to watch the .slnx solution of its users. It adds one Compile line to the old-style test project, which the SDK-style conversion later in this chain makes unnecessary.

Verification

  • A full rebuild through the .slnx with the MSBuild of Visual Studio 2026 (18.12) gives no errors, the same 26 distinct warnings as main, the same VSIX content (37 entries in Debug and in Release), and the 4 tests pass. The machine has no .NET Framework 4.8.1 targeting pack, so the old-style projects were built with -p:TargetFrameworkVersion=v4.8, before and after.
  • The workflows of this repository wait for the approval of a maintainer on a pull request, so the commit ran in a fork. Build restores and builds the .slnx with msbuild /v:m -restore /p:OutDir=\_built on windows-2022 (MSBuild 17.14.60; the command does not name the solution), runs the 4 tests and uploads the VSIX, which has the same 37 entries and sizes as the one built from main (run). 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.
  • Not verified: opening the solution in a Visual Studio 2022 older than 17.13.

🤖 Generated with Claude Code

`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>
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