product-resources
VS 2022 + VS 2026 breaks Puma Scan Server Edition scanning and DFA due to a Roslyn MSBuildWorkspace bug. Symptoms, affected editions, and workaround.
When Visual Studio 2026 (with the .NET 10 SDK) is installed on the same machine as Visual Studio 2022, Puma Scan’s data flow analysis (DFA) engine fails to load. Affected users will see DFA-based findings either not reported at all (Server Edition) or stuck in a pending state that never resolves (End User Edition 2.0+).
Users who have both Visual Studio 2022 and Visual Studio 2026 installed on the same machine. VS 2026 ships with the .NET 10 SDK, which introduces the assembly incompatibility described below.
| Server Edition | End User Edition 2.0+ | End User Edition < 2.0 | |
|---|---|---|---|
| DFA findings (on-demand scan / CLI) | Fails — scan will not complete | Findings remain pending indefinitely | Unaffected |
| Live analysis rules in Visual Studio | N/A | Still works normally | Still works normally |
The DFA engine uses Roslyn’s MSBuildWorkspace to load and compile projects. Live analysis rules in Visual Studio use a different code path and are not affected.
When the incompatibility is present, you will see one or both of the following exceptions in the scanner output:
System.TypeInitializationException: The type initializer for 'Microsoft.Build.Evaluation.ProjectCollection' threw an exception.
---> System.TypeInitializationException: The type initializer for 'XMakeElements' threw an exception.
System.MissingMethodException: Method not found: 'System.Collections.Frozen.FrozenSet`1 System.Collections.Frozen.FrozenSet.Create(...)'
This is an upstream bug in Roslyn’s MSBuildWorkspace — not a Puma Scan defect. When VS 2026 is installed alongside VS 2022, the MSBuildWorkspace BuildHost process resolves MSBuild assemblies from VS 2026’s MSBuild directory instead of the VS 2022 directory. The VS 2026 assemblies are incompatible with the .NET runtime target used by MSBuildWorkspace, causing the type initialization failures above.
This same issue affects other tools that depend on Roslyn’s MSBuildWorkspace, including dotnet format, dotnet watch, DocFX, and similar analyzers.
A community-provided script in the Visual Studio Developer Community ticket resolves the assembly conflict by redirecting MSBuildWorkspace to the correct VS 2022 MSBuild directory. The script must be tailored to your build server’s environment before running — update the following paths to match your installation:
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild)Alternatively, uninstall Visual Studio 2026 to eliminate the conflict until an upstream fix is available.
The DevCommunity script applies to the Server Edition CLI and does not resolve the issue for the Visual Studio extension. The available options are:
We are monitoring the upstream fix in the Roslyn repository. Once the fix is available in a stable SDK release, we will ship a Puma Scan update to pick up the corrected MSBuildWorkspace behavior. Watch the release notes for updates.
https://github.com/dotnet/roslyn/issues/82931