Skip to content

Support Visual Studio 2026 and write args to the active VC configuration - #199

Open
CoreyShay wants to merge 1 commit into
MBulli:masterfrom
CoreyShay:fix/vs2026-support
Open

Support Visual Studio 2026 and write args to the active VC configuration#199
CoreyShay wants to merge 1 commit into
MBulli:masterfrom
CoreyShay:fix/vs2026-support

Conversation

@CoreyShay

Copy link
Copy Markdown

Problem

The extension cannot be used with Visual Studio 2026 (18.x):

  1. The VSIX refuses to install, because the VS2022 InstallationTarget is capped at [17.0, 18.0).
  2. After installing it anyway, arguments set in the tool window are never applied to C/C++ projects. The tool window works, the args.json is written, but the project keeps its old arguments and the debugged process does not receive them.

Cause

For C/C++ projects, SetVCProjEngineConfig writes to VCProject.ActiveConfiguration.

In VS2026 that property can return a configuration which is not the one currently selected. In my case the active configuration was BattleNet_GameTest|x64, but the arguments were written into the BattleNet_GameProfileSecured|x64 group of the .vcxproj.user — so the configuration actually being debugged never saw them.

The arguments themselves are selected using Project.ConfigurationManager.ActiveConfiguration (ItemAggregationService), so the read side and the write side disagreed about which configuration is active.

There is already precedent for Project.Object.ActiveConfiguration being unreliable: the Fortran path (SetVFProjEngineConfig) deliberately uses ConfigurationManager.ActiveConfiguration, with a comment noting that Project.Object.ActiveConfiguration throws a RuntimeBinderException there.

Fix

Add GetActiveVCConfiguration, which resolves the VCConfiguration by matching "{ConfigurationName}|{PlatformName}" (the format of VCConfiguration.Name) from Project.ConfigurationManager.ActiveConfiguration against VCProject.Configurations.

This makes the read side and the write side agree. If no match is found, it logs a warning and falls back to the previous VCProject.ActiveConfiguration, so behaviour on older Visual Studio versions is unchanged.

The manifest change widens the existing Microsoft.VisualStudio.Community targets (amd64 and arm64) from [17.0, 18.0) to [17.0, 19.0). It also normalises the arm64 entry, which was missing a space and read [17.0,18.0).

Verification

Verified in Visual Studio 2026 Enterprise 18.7.11903.348 against a large C++ solution:

  • Before: arguments written to the wrong configuration group in .vcxproj.user.
  • After: arguments written to the active configuration and correctly applied on launch.

Also verified that the VSIX still builds and the unit test suite passes (39/39).

Notes

This is rebased on top of #197, so it sits directly below the new LoadVCPropInfo().

Happy to split the manifest bump and the configuration fix into separate PRs if you would prefer that, or to adjust how VS2026 is targeted — for example a dedicated SmartCmdArgs18 project instead of widening the VS2022 range.

Two changes are needed to make the extension usable in VS2026 (18.x):

1. Widen the VS2022 InstallationTarget from [17.0, 18.0) to
   [17.0, 19.0) so the VSIX can be installed at all.

2. For C/C++ projects the arguments were written to the configuration
   returned by VCProject.ActiveConfiguration. In VS2026 that can be a
   different configuration than the one which is actually active, so the
   arguments were written to the wrong configuration in the
   .vcxproj.user file and nothing was applied to the project being
   debugged.

   The arguments are selected using
   Project.ConfigurationManager.ActiveConfiguration (see
   ItemAggregationService), so resolve the VCConfiguration by matching
   "Configuration|Platform" against VCProject.Configurations to make the
   read and the write agree. If no match is found the previous behaviour
   is used as a fallback.

   The VFProjEngine (Fortran) path already avoided
   Project.Object.ActiveConfiguration for a similar reason.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.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