[xperiandri]

Summary

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

This pull request converts the extension project and the test project to the SDK style (Microsoft.NET.Sdk, net481), which Visual Studio 2026 18.5 and later expects of an extension project (SDK-style support for extension projects). It requires #53: its StringResourceVisualizer.slnx gets the <Deploy> element here. It does not depend on the AI pull request #54; both start at #53. The matching update of the instructions is part of the last pull request of the chain (#69), because the instructions live in the files that #54 adds. The 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 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)
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) – this pull request
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

• The extension project goes from 181 to 82 lines, the test project from 104 to 31. The files are included by globbing, so the lists of Compile items are gone; Update items keep the metadata that the designers and the generator need (OptionsGrid.cs is a component, source.extension.cs depends on the manifest and its custom tool). The test project lies inside the folder of the extension project, so the extension project excludes StringResourceVisualizer.Tests\** from its globbing.
• GenerateAssemblyInfo is off in both projects (the AssemblyInfo.cs files stay, and the version comes from the Vsix constants), AppendTargetFrameworkToOutputPath is off (the output stays in bin\Debug\ and bin\Release\, where the workflow and the signing step expect it), and CopyOutputSymbolsToOutputDirectory stays false as it was.
• VSSDKBuildToolsAutoSetup with Microsoft.VSSDK.BuildTools 18.5.40034, which adds the VsixSdkStyle project capability, builds the VSIX; GeneratePkgDefFile, UseCodebase and the two IncludeDebugSymbolsIn... properties keep their values. The package is the only addition to the package list, and the versions are the old ones.
• Gone: ProjectGuid and ProjectTypeGuids (the solution holds the project id), the start options (StartAction, StartProgram, StartArguments), the per-configuration property groups, SignAssembly (it was true with an empty key file, so the assembly was not signed before and is not now), MinimumVisualStudioVersion, the explicit imports of the common and the VSSDK targets, NuGetPackageImportStamp, the empty EnsureNuGetPackageBuildImports target and the properties that repeat a default. The framework references that are not implicit stay.
• src/signvsix.targets: the target is renamed from AfterBuild to SignAndCopyVsix and runs AfterTargets="Build" (see below).
• StringResourceVisualizer.slnx marks the extension project with <Deploy Solution="Debug|Any CPU" />, which Visual Studio needs to deploy it on F5.

Things to know

• Visual Studio: F5 into the Experimental instance relies on the SDK-style VSIX support of Visual Studio 2026 18.5 and later. Building does not: the CI run below uses the MSBuild of Visual Studio 2022 17.14. I did not try to open the projects or press F5 in Visual Studio 2022, so a contributor who works there may be able to build but probably not to start the extension.
• The signing target: in an SDK-style project the SDK targets are imported after this file and replace a target named AfterBuild, so the signing would silently never run. I checked that with a fake sign tool: with SM_CERT_FP_SHA256 set, a Release build of the old project and of the new one call the tool with the same arguments after the VSIX exists and then create the versioned copy StringResourceVisualizer.1_23_3.vsix; with the old target name the tool is never called. I could not run the real signing.
• Compiler: an SDK-style project is compiled with the Roslyn of the .NET SDK that MSBuild resolves, not with the one of Visual Studio. The compiled types, methods and IL sizes are the same with the .NET SDK 10.0.402.
• The VSIX: it has the same assemblies, manifest and pkgdef as before. Three .pdb files of NuGet packages (Microsoft.ApplicationInsights, Microsoft.CodeAnalysis.Scripting and Microsoft.DiaSymReader, about 1.7 MB in Debug) are no longer in it, because the SDK does not copy the symbols of packages next to the assemblies (14 such files are gone from bin too), and the .pdb of the extension is a portable PDB now, about a quarter of the size. Resources\LICENSE is copied to the output folder as well.
• The code has one #if (#if !DEBUG), so the new predefined symbols (NETFRAMEWORK, NET481, NET48_OR_GREATER and so on) change nothing. The NuGet audit warnings (NU1902 and NU1903 for MessagePack) now appear twice in the build log, because the SDK repeats the restore warnings at build time; the distinct warnings are the same.
• Watch .slnx solution files as well as .sln #51 adds <Compile Include="StringExtensionsTests.cs" /> to the old test project. With globbing that line is not needed, so whichever of the two is merged second needs a trivial rebase.

Verification

• Compared with main in Debug and Release (the MSBuild of Visual Studio 2026 18.12; the old projects with -p:TargetFrameworkVersion=v4.8, the new ones with net481, because the machine has no 4.8.1 targeting pack): the same 26 distinct warnings; the same 19 compile items; the same references apart from five that the SDK and the build tools add; identical fingerprints of both assemblies (references, resources, every type and method with the IL size); the same VSIX entries apart from the three .pdb files and the sizes of the extension's own files (and of manifest.json and catalog.json, which list them); identical extension.vsixmanifest, pkgdef and content types; the 4 tests pass. A second build with the stable .NET SDK 10.0.402 (the machine's default is a preview) gives the same.
• CI: the workflows of this repository wait for the approval of a maintainer on a pull request from a fork, so the commit ran in a fork on a clean windows-2022 runner: Build builds the solution and runs the 4 tests, which pass. As on the unchanged main (run), the step Publish Test Results fails there: the third-party action EnricoMi/publish-unit-test-result-action finds no Python interpreter on the image. This pull request neither causes nor changes it.
• After the chain was re-cut so that this pull request no longer contains the files of Add instructions, skills and MCP configuration for AI coding agents #54, the tip was built again locally with the MSBuild of Visual Studio 2026 (no errors, the same distinct warnings as the pull request before it).
• Not verified: F5 and the extension running in the Experimental instance (Visual Studio 2026 18.5 or later is needed), the same in Visual Studio 2022, and the signing with the real certificate.

🤖 Generated with Claude Code