fix the assembly resolver to prevent recursion and version mismatches

[lukka]

Prevent StackOverflow exceptions in Visual Studio 2026 for users who have ExtensionManager installed: fixed the assembly resolver to prevent recursion and version mismatches

[loop8ack]

See my review comments.

Regarding package references:

Why are these packages added to all projects:

• Community.VisualStudio.Toolkit.15
• MessagePack
• Microsoft.IO.Redist
• System.Text.Json

The adapter project is designed to resolve version conflicts at runtime via IL generation. Adding Toolkit.15 to all core projects breaks this isolation.

Also, System.Text.Json should only be updated in the Manifest project where it's actually used.

---

PS: Sorry for any email spam earlier – I was testing Rider's GitHub review tools, but they turned out to be buggy

[lukka]

See my review comments.

Regarding package references:

Why are these packages added to all projects:

• Community.VisualStudio.Toolkit.15
• MessagePack
• Microsoft.IO.Redist
• System.Text.Json

The adapter project is designed to resolve version conflicts at runtime via IL generation. Adding Toolkit.15 to all core projects breaks this isolation.

Also, System.Text.Json should only be updated in the Manifest project where it's actually used.

PS: Sorry for any email spam earlier – I was testing Rider's GitHub review tools, but they turned out to be buggy

@loop8ack thank you for the quick review! I reduced the scope of this PR to really what is necessary. I still kept the bump on Text.Json pacakge for a critical vulnerability, but dropped all the other unnecessary changes.

The goal of this PR is to prevent a potential stack overflow caused by the extension’s assembly resolver. When the C++ workload (“Desktop development with C++” in VS2026) is not installed, the extension ships its own copy of MS.VS.VCProjectEngine.dll, but at version 17 rather than the current version 18 provided by the workload. Because of the binding redirect and the legacy .NET Framework assembly resolution behavior (different from modern .NET), this can trigger a recursive resolution loop that leads to a stack overflow. The changes in this PR avoid that issue by ensuring the attempt to load the older v17 VCProjectEngine.dll happens only once.

[loop8ack]

I tried to reproduce the error, but it works for me with Visual Studio 2026 Insiders (11312.210)

Do you have any further information about the recursion? Do you know which libraries are responsible for it and how they reference each other?

I'm also a little hesitant about your solution:

• _nestingCount would prevent another assembly from being loaded when one assembly is loaded, but is that relevant?
• The version match check prevents other versions from being loaded, even if they are actually compatible.