Microsoft.Extensions.Logging.Abstractions Error in vscode only.

[justcain-ok]

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

I get an error when I use a PowerShell to leverage packages that have a dependency on Microsoft.Exentions.Logging.Abstractions.

.NET SDK:
Version: 7.0.202
Commit: 6c74320bc3

Runtime Environment:
OS Name: Mac OS X
OS Version: 13.2
OS Platform: Darwin
RID: osx.13-arm64
Base Path: /usr/local/share/dotnet/sdk/7.0.202/

Host:
Version: 7.0.4
Architecture: arm64
Commit: 0a396acafe

.NET SDKs installed:
6.0.407 [/usr/local/share/dotnet/sdk]
7.0.202 [/usr/local/share/dotnet/sdk]

Microsoft.Extensions.Logging.Abstractions have no dependencies themselves when using net6.0 or net7.0. This works perfectly fine in the terminal on the same device, but throws an error in vs code with the PowerShell extension:

Could not load file or assembly 'Microsoft.Extensions.Logging.Abstractions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9743819ddae60'. Could not find or load a specific file. (0x80131621)

PowerShell Version

PSVersion                      7.3.3
PSEdition                      Core
GitCommitId                    7.3.3
OS                             Darwin 22.3.0 Darwin Kernel Version 22.3.0: Mon Jan 30 20:39:46 PST 2023; root:xnu-8792.81.3~2/RELEASE_ARM64_T6020
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visual Studio Code Version

1.76.2
ee2b180d582a7f601fa6ecfdad8d9fd269ab1884
arm64

Extension Version

[email protected]

Steps to Reproduce

The fastest way to reproduce it is to download https://github.com/nightroman/Mdbc and import and run Connect-Mdbc.
Or download MongoDB.Driver 2.19.0 and try to connect to a db:

add-type -Path .MongoDB.Driver.dll
$mongo=new-object mongodb.driver.mongo

etc

Visuals

Logs

No response

[andyleejordan]

It looks like Mdbc depends on MongoDB.Driver which requires Microsoft.Extensions.Logging ">= 2.0.0"...and we're including in 7.0.0 in PSES. Which given the stated >= requirement should satisfy their project. But the error (and their csproj when I read it) indicates that's actually a == requirement. So when our ALC returns 7.0.0 for the given assembly, it doesn't work. Hm.

[andyleejordan]

I'm actually not able to repro this. I installed the Mdbc module, imported it, tried Connect-Mdbc (though without a database to connect to) and got no errors. Checking which assemblies are loaded I see:

False  v4.0.30319     /Users/andschwa/.local/share/powershell/Modules/Mdbc/6.6.4/Mdbc.dll
False  v4.0.30319     /Users/andschwa/.local/share/powershell/Modules/Mdbc/6.6.4/MongoDB.Bson.dll
False  v4.0.30319     /Users/andschwa/.local/share/powershell/Modules/Mdbc/6.6.4/MongoDB.Driver.Core.dll
False  v4.0.30319     /Users/andschwa/.local/share/powershell/Modules/Mdbc/6.6.4/MongoDB.Driver.dll
False  v4.0.30319     /Users/andschwa/.local/share/powershell/Modules/Mdbc/6.6.4/MongoDB.Libmongocrypt.dll
False  v4.0.30319     /usr/local/microsoft/powershell/7/System.Diagnostics.TextWriterTraceListener.dll
False  v4.0.30319     /Users/andschwa/.local/share/powershell/Modules/Mdbc/6.6.4/Microsoft.Extensions.Logging.Abstractions.dll

It sure looks like Microsoft.Extensions.Logging.Abstractions.dll is getting loaded from Mdbc's dependencies...I'll try to see if I can break it.

[andyleejordan]

Yup, I verified that both ours and theirs is loaded without issue:

@andys-mac-mini ~/src
> [appdomain]::CurrentDomain.GetAssemblies() | Select-String Microsoft.Extensions.Logging.Abstractions

Microsoft.Extensions.Logging.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60

@andys-mac-mini ~/src
> Import-Module Mdbc                                                                                  
@andys-mac-mini ~/src
> Connect-Mdbc -ConnectionString mongodb://localhost:27017
@andys-mac-mini ~/src
> [appdomain]::CurrentDomain.GetAssemblies() | Select-String Microsoft.Extensions.Logging.Abstractions

Microsoft.Extensions.Logging.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60
Microsoft.Extensions.Logging.Abstractions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60

@andys-mac-mini ~/src
> $psEditor.EditorServicesVersion          

Major  Minor  Build  Revision
-----  -----  -----  --------
3      8      2      0

[andyleejordan]

@justcain-ok can you give me more details? Can you verify that you actually have all of Mdbc's dependencies installed? I think you really are just missing Microsoft.Extensions.Logging.Abstractions, Version=2.0.0.0 with however you're trying to do this.

[justcain-ok]

@andschwa , so that got me in the right direction, this is weird. When I checked assemblies I got this output:

Microsoft.Extensions.Logging.Abstractions, Version=7.0.0.0, Culture=neutral,
PublicKeyToken=adb9793829ddae60
Microsoft.Extensions.Logging.Abstractions, Version=1.1.1.0, Culture=neutral,
PublicKeyToken=adb9793829ddae60

So, just get why. Can it because is synced settings to vscode?

[andyleejordan]

I have a suspicion...do you have any other modules imported that may be requiring Microsoft.Extensions.Logging.Abstractions? Such as in your profile. Here's the thing about assembly load contexts...they only work if each and every module (such as PSES) is using one correctly. As soon as any module imports a conflicting dependency without an ALC for isolation, things break.

So, what's the path of Microsoft.Extensions.Logging.Abstractions, Version=1.1.1.0 when you run [appdomain]::CurrentDomain.GetAssemblies()? (Without the select-string it should show full path too).

[justcain-ok]

GAC Version Location

---

False v4.0.30319 /Users/x/.local/share/powershell/Modules/Az.IotHub/2.7.5/Microsoft.Extensions.Logging.Abstractions.dll

But that module is loaded in "terminal" as well.

[justcain-ok]

@andschwa Well its solved now, if you ever meet me tap my shoulder and you can have a beer, or what ever is to your liking, thank you so much!

[andyleejordan]

Sure looks to me like the Azure module developers implemented an AssemblyLoadContext for their Accounts module...and nothing else, looking at this search: https://github.com/search?q=repo%3AAzure%2Fazure-powershell+AssemblyLoadContext+path%3A%2F%5Esrc%5C%2F%2F+language%3AC%23&type=code&l=C%23

I browsed through the Az.IotHub module's sources in that same repo and it sure enough depends on a conflicting version of Microsoft.Extensions.Logging.Abstractions.dll, and does not have an ALC to isolate it 🥲

[andyleejordan]

Interestingly they have an AlcWrapper in their source...but yeah I don't see it in use for Az.IotHub.

@justcain-ok I'll be at PSConfEU this year if you happen to be there!

[htcfreek]

Did you find any solution? I have a similar problem with the Yubico.NET.SDK (Yubico/Yubico.NET.SDK/issues/184).

[JustinGrote]

@htcfreek the latest preview isolates a lot of dependencies including logging into an ALC, so it should prevent conflicts in this regard with vscode/PSES itself, however we cannot prevent conflicts between modules, but there should be a lot less that only conflicts in vscode but doesn't conflict in PowerShell

Also note that the intellisense and scriptanalyzer will opportunistically load modules to do analysis so it may seem to only happen in vscode when in reality it would happen if you loaded these modules in that order in a normal pwsh as well, you may need to disable those or load them in your profile if they are required in a specific order (you must load higher versioned dependencies above lower versioned ones to avoid a conflict, and even then it's not guaranteed if there was a breaking change such as the removal of a method that was depended upon)

And, as usual, 5.1 doesn't follow any of these rules and is best effort so we recommend you use 7+ to author scripts (those scripts can still be 5.1 compatible)