Same assembly was loaded into multiple contexts of an application domain

[isra-fel]

Prerequisites

• I have written a descriptive issue title.
• I have searched all open and closed issues to ensure it has not already been reported.
• I have read the troubleshooting guide.
• I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
• I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
• If this is a security issue, I have read the security issue reporting guidance.

Summary

When opening a Windows PowerShell (x64) session in the embedded VSCode terminal, I found an error in fusion log (assembly binding log) saying Newtonsoft.Json was "loaded into multiple contexts of an application domain" and "might lead to runtime failures". I am not sure if this caused modules such as "Az.Accounts" behaving incorrectly in this session (see Not able to connect to Azure with Az.Accounts version 2.12.3 (get_SerializationSettings) from within Visual studio code), but please review the design and let us know if it's intentional or not.

Fusion log:

*** Assembly Binder Log Entry  (2025/1/20 @ 10:09:44 AM) ***

The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll
Running under executable  C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe
--- A detailed error log follows. 

WRN: The same assembly was loaded into multiple contexts of an application domain:
WRN: Context: LoadFrom | Domain ID: 1 | Assembly Name: Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
WRN: Context: Neither | Domain ID: 1 | Assembly Name: Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed
WRN: This might lead to runtime failures.
WRN: It is recommended to inspect your application on whether this is intentional or not.
WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue.

These are the two Newtonsoft.Json assemblies that are loaded to the session, one net45 from PSScriptAnalyzer, another netstandard2.0 from PowerShellEditorServices.

FullName            : Newtonsoft.Json, Version=13.0.0.0, Culture=neutral,
                      PublicKeyToken=30ad4fe6b2a6aeed
Location            : C:\Users\yeliu\.vscode\extensions\ms-vscode.powershell-2024.4.0\ 
                      modules\PSScriptAnalyzer\1.23.0\Newtonsoft.Json.dll
AssemblyFileVersion : 13.0.3.27908
TargetFramework     : .NETFramework,Version=v4.5

FullName            : Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, 
                      PublicKeyToken=30ad4fe6b2a6aeed
Location            : C:\Users\yeliu\.vscode\extensions\ms-vscode.powershell-2024.4.0\ 
                      modules\PowerShellEditorServices\bin\Common\Newtonsoft.Json.dll  
AssemblyFileVersion : 13.0.3.27908
TargetFramework     : .NETStandard,Version=v2.0

PowerShell Version

Name                           Value
----                           -----
PSVersion                      5.1.26100.2161
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.26100.2161
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Name             : Visual Studio Code Host
Version          : 2024.4.0
InstanceId       : 1f8d7bfb-7399-4b83-a114-5d5cfa983ec5
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterfac 
                   e
CurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace

Visual Studio Code Version

1.96.4
cd4ee3b1c348a13bafd8f9ad8060705f6d4b9cba
x64

Extension Version

ms-vscode.powershell@2024.4.0

Steps to Reproduce

1. Open Fuslogvw.exe (Assembly Binding Log Viewer) and enable "Log all bindings in disk" in the settings - https://learn.microsoft.com/en-us/dotnet/framework/tools/fuslogvw-exe-assembly-binding-log-viewer
2. Open a .ps1 script to activate the extension
3. Open a integrated terminal of Windows PowerShell (x64)
4. You should be able to find an entry like "LoadFile!FileName=(Newtonsoft.Json.dll)", the warning message is in it.

Visuals

No response

Logs

No response

[JustinGrote]

@isra-fel thanks for your submission!

Can you reproduce this in PowerShell 7? 5.1 has no ability to isolate dependencies, so if two modules load different versions of the same assembly (Newtonsoft being one of the prime offenders because it's so common) you will see errors like this.

PowerShell 7 (and the .NET version it is based upon) does have ability to isolate these dependencies, so we recommend you use PowerShell 7 to resolve this. There's nothing we can do otherwise.

[isra-fel]

Thanks @JustinGrote ! It doesn't reproduce on PS 7. It's just there are still a lot of customers using the extension with Windows PowerShell.
I understand that assembly loading on Windows PowerShell is not super flexible, but the warning message still bothers me. Can both PSES and PSSA use the same Newtonsoft.Json, I mean netstandard2.0? Can they load the assembly in the same way?

Regards

[JustinGrote]

That's a limitation of PS5.1, there's not much we can do in that regard because if we downgrade newtonsoft json to match PSSA, it breaks compatibility with other things.

Our recommendation is to author your PS 5.1 scripts in PS7. PS5.1 is only best effort supported in the vscode extension per the readme.