{{ message }}
Repository navigation
Unable to load Az modules - Assembly with same name is already loaded #4727
Description
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
If you load a PowerShell file that has references to Azure PowerShell commands the assemblies are being loaded without loading the module fully.
This is repeat of #3012 which was closed with no solution. Extensions do not matter in this case, it is when a file that has Azure module references is opened the assemblies get loaded but not the actual modules.
PowerShell Version
> $PSVersionTable
Name Value
---- -----
PSVersion 7.2.13
PSEdition Core
GitCommitId 7.2.13
OS Darwin 21.6.0 Darwin Kernel Version 21.6.0: Thu Jul 6 22:20:00 PDT 2023; root:xnu-8020.240.18.702.13~1/RELEASE_A…
Platform Unix
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0Visual Studio Code Version
> code-insiders --version
1.82.0-insider
f1302be1e67e3af5fbeb8bbb2ea784de7bc96150
arm64Extension Version
> code --list-extensions --show-versions | Select-String powershell
ms-vscode.powershell@2023.6.0Steps to Reproduce
- Close all PowerShell files
- Restart session for PowerShell Extension
- Run following command to list loaded assemblies
[System.AppDomain]::CurrentDomain.GetAssemblies() | Where-Object Location | Sort-Object -Property FullName | Select-Object -Property FullName, Location, GlobalAssemblyCache, IsFullyTrusted | Where FullName -like '*azure*' | ft
- Note nothing is returned
- Run
Get-Module Az* - Nothing is returned
- Open file (any file) with Az PowerShell references
- Rerun step 3
- All assemblies for the Az.Accounts and related commands are loaded
- Rerun step 5
- Nothing is returned
- Run
Import-Module Az.Accounts - Error returned:
Import-Module: Assembly with same name is already loaded
Activity
SydneyhSmith commentedon Sep 6, 2023
Thanks Shawn Melton (@wsmelton) , to clarify is this a new issue for you or has this been happening on previous versions of the extension?
"If you load a PowerShell file that has references to Azure PowerShell commands the assemblies are being loaded without loading the module fully." We think this is happening from a
Get-Helpcall in tab completionIt looks like the error itself may be coming from our resolve handler or something similar
wsmelton commentedon Sep 6, 2023
Always happening since I started using an Apple device (M1), switched to this month ago. I can't recall if Windows device gives me this issue...I can test that shortly.
Extension versions I tried
v2023.6.0back tov2023.3.3, issue exist in all of them.wsmelton commentedon Sep 6, 2023
So I cannot replicate this on Windows (Windows 10, VS Code Insiders, PowerShell 7.2, and
v2023.9.1).andyleejordan commentedon Sep 6, 2023
Well, that's interesting. Usually it's the other way around (issue occurs on Windows but nowhere else).
wsmelton commentedon Sep 6, 2023
I'll grab diagnostic logs for the windows device I used tomorrow and upload them.
andyleejordan commentedon Sep 7, 2023
Shawn Melton (@wsmelton) could you share your PSSA settings file? We noticed:
and believe there is a PSSA rule that can cause modules to be imported when analyzing the file.
wsmelton commentedon Sep 7, 2023
There is no PSSA settings file in the referenced project
We have this in most of the project's settings.json file:
"powershell.scriptAnalysis.settingsPath": "./ScriptAnalyzerSettings.psd1"andyleejordan commentedon Sep 7, 2023
Your log said it loaded '/Users/smelton/ldx/Agents/ScriptAnalyzerSettings.psd1', is there anything in that file? Could be a bug that it found it but might be what's going on.
andyleejordan commentedon Sep 7, 2023
Oh wait nevermind also in the log:
And I misread that earlier.
11 remaining items
randriksen commentedon Nov 26, 2023
I'm seeing the same issue with Az.Accounts. And it's really annoying when that module is the best way to get authorization tokens to work with any of the Azure related Rest API's. Should we also report it as a bug for the Az module?
tropez1971 commentedon Nov 28, 2023
Same here, pain in the butt. No current workaround.
andyleejordan commentedon Nov 29, 2023
Yes please.
tropez1971 commentedon Nov 30, 2023
Found a workaround. If I do a forced update of both the Az.Storage and Az.Accounts modules, I’m back to working.
PaulBendall commentedon Mar 13, 2024
I'm seeing this issue with MS Graph SDK. Is there an idiot's guide to implementing Andy Jordan (@andyleejordan) recommendation? I found that when I want to Debug code the PIC is used regardless of having the
powershell.integratedConsole.startInBackgroundto hide.lbouriez commentedon Jun 7, 2024
I am trying to do a remove and import of these 2 but I still get the issue. Can you post your workaround, maybe i am missing something
JustinGrote commentedon Jun 10, 2024
Paul Bendall (@PaulBendall) the issue has nothing to do with vscode specifically, basically what happens is that the Az modules have some common .NET libraries, and if one loads a lower version before another one that requires a higher version, that module will run into an error. It's even worse in PowerShell 5.1 vs 7 because assembly binding redirects aren't a thing.
It appears to happen more in vscode because the engine that makes vscode work, despite hiding some things properly, still has some common DLLs it has to load that might conflict
The best thing to do is to clean out all your Az modules, and then install specifically the ones you need at the same time with
Install-PSResourceto ensure you get the correct interdependencies, and then update all those modules together.Also, you may have other modules loaded that use the same DLLs as Az (such as Azure.Identity). Ideally you load those in your system after Az and on Powershell 7+ so that binding redirects can work. Also keep your vscode extension up to date.
That's the best advice I can offer.
o-l-a-v commentedon Oct 1, 2024
I made an issue in both the Azure PowerShell (
Az) and the Microsoft Graph SDK PowerShell (Microsoft.Graph) repos.Az: Implement proper assembly isolation to play nice withvscode-powershellAzure/azure-powershell#26206Microsoft.Graph: Implement proper assembly isolation to play nice withvscode-powershellmicrosoftgraph/msgraph-sdk-powershell#2978Could someone more knowledgeable than me about "proper assembly isolation" chime in in respective issues on how they should proceed to fix this? Is there a best practice reference guide? Or a reference module that does this right?
Edit: Other modules:
PnP.PowerShell:Edit 2: Created PowerShell discussion about this topic:
JustinGrote commentedon Oct 1, 2024
It's called an Assembly Load Context, and I believe Az already has it partially implemented but they use it to hide only one assembly which doesn't really do the trick :). Also this would be for PS7+ only, wouldn't work for PS5.1
https://learn.microsoft.com/en-us/dotnet/api/system.runtime.loader.assemblyloadcontext?view=net-8.0
andyleejordan commentedon Oct 1, 2024
It is very strange what Az does with their ALC. Some modules use it to hide a one (or a few) assemblies, some don't use it all. None of them use it correctly. Granted, "correct" is hard to get right with ALC and it's a ridiculous ask of module others, but is unfortunately just how .NET apps work.
o-l-a-v commentedon Oct 2, 2024
As Microsoft seems to be focusing on security lately for many projects: Can ALC be an argument for better security?
matthiashaldimann commentedon Oct 6, 2024
Not a solution, but a workaround that may help some of you while we wait for a fix:
I am able to avoid the conflict between Microsoft.Graph and vscode's Powershell extension by using the
PowerShell Launch Current File in Temporary Console
debug configuration instead of the
PowerShell Launch Current File
debug configuration. I am not using Az, but it's not unlikely that the same workaround works for this module too.
JustinGrote commentedon Oct 6, 2024
Matthias Haldimann (@matthiashaldimann) that's a pretty good workaround as the temp console doesn't load PSES, so it won't have the same assembly conflicts.
SamErde commentedon Mar 12, 2026
I just released v1.0 of my DLL Pickle module that prevents most cases of these DLL version conflicts. Please try it out and let me know your results!