Repository navigation
Can't import v1.0.2 to pwsh.exe v7.4.1 with error "Import-Module: Assembly with same name is already loaded" #21201
Description
Activity
- addedNeeds-TriageThe issue is new and needs to be triaged by a work group.The issue is new and needs to be triaged by a work group.
on Feb 8, 2024 - changed the title
[-]Can't import v1.0.2 to VSCode with error "Import-Module: Assembly with same name is already loaded"[/-][+]Can't import v1.0.2 to pwsh.exe v7.4.1 with error "Import-Module: Assembly with same name is already loaded"[/+]on Feb 8, 2024 Seems it has something to do with PSResourceGet v1.0.1 being included in PowerShell v7.4.1.
I deleted the whole
%ProgramW6432%\PowerShell\7\Modules\Microsoft.PowerShell.PSResourceGetdirectory, then v7.4.1 managed toImport-Module -Name 'Microsoft.PowerShell.PSResourceGet' -RequiredVersion 1.0.2.It also works as expected if adding a version directory to the v7.4.1 included PSResourceGet. So was originally:
%ProgramW6432%\PowerShell\7\Modules\Microsoft.PowerShell.PSResourceGet\<content>Became:
%ProgramW6432%\PowerShell\7\Modules\Microsoft.PowerShell.PSResourceGet\1.0.1\<content>Additional info:
- With Windows PowerShell, included modules are added to a version directory (
<modulename>\<version>\<content>). - PSResourceGet, PowerShellGet and PackageManagement installs modules to
<modulename>\<version>\<content>. - PowerShell Core does not have this version directory for included modules, so
<modulename>\<content>instead of<modulename>\<version>\<content>.
This might be an issue with how
Import-Moduleworks? Related issues:And PScriptAnalyzer might be relevant here too? Simply opening a given script in VSCode loads PSResourceGet assemblies. I think this can be a related issue:
- With Windows PowerShell, included modules are added to a version directory (
Can you run
Get-Moduleafter starting a new session?PowerShell 7.4.1 PS C:\Users\olavb> Get-Module ModuleType Version PreRelease Name ExportedCommands ---------- ------- ---------- ---- ---------------- Script 2.3.4 PSReadLine {Get-PSReadLineKeyHandler, Get-PSReadLineOption, … PS C:\Users\olavb>
I could repro with another module too, so does not seem to be the issue of PSResourceGet?
Olav Rønnestad Birkeland (@o-l-a-v) Thanks for the info, we're going to send this over to PowerShell/PowerShell
adityapatwardhan commented
on Feb 8, 2024 MemberMore actionsThe issue is about loading modules and not specific to PowerShellResourceGet. Transferring over to PowerShell/PowerShell repository.
- transferred this issue fromPowerShell/PSResourceGet
on Feb 8, 2024 Here is an easy and reliable repro of this issue.
Prerequisite: Module of lower version must not be inside a versioned folder.
- This is what happens when PSResourceGet is embedded inside a PowerShell release, but not in a versioned directory.
Does not repro:
ModulesAllVersioned ├─ Modules1 │ └─ Microsoft.PowerShell.PSResourceGet │ └─ 1.0.6 │ └─ <content> └─ Modules2 └─ Microsoft.PowerShell.PSResourceGet └─ 1.1.0 └─ <content>Does repro:
ModulesFirstNotVersioned ├─ Modules1 │ └─ Microsoft.PowerShell.PSResourceGet │ └─ <content> └─ Modules2 └─ Microsoft.PowerShell.PSResourceGet └─ 1.1.0 └─ <content>Repro:
- Start PowerShell with no profile:
pwsh -NoProfile
# Set PSModulePath in process scope $env:PSModulePath = ( '{0}\ModulesFirstNotVersioned\Modules1;{0}\ModulesFirstNotVersioned\Modules2' -f [System.Environment]::GetFolderPath('Desktop') ) # Import Microsoft.PowerShell.PSResourceGet v1.1.0 Import-Module -Name 'Microsoft.PowerShell.PSResourceGet' -RequiredVersion 1.1.0 -Verbose -Debug
This gives:
PS > Import-Module -Name 'Microsoft.PowerShell.PSResourceGet' -RequiredVersion 1.1.0 -Verbose -Debug VERBOSE: Loading module from path 'C:\Users\olavb\Desktop\ModulesFirstNotVersioned\Modules1\Microsoft.PowerShell.PSResourceGet\Microsoft.PowerShell.PSResourceGet.psd1'. VERBOSE: Loading module from path 'C:\Users\olavb\Desktop\ModulesFirstNotVersioned\Modules2\Microsoft.PowerShell.PSResourceGet\1.1.0\Microsoft.PowerShell.PSResourceGet.psd1'. VERBOSE: Loading 'FormatsToProcess' from path 'C:\Users\olavb\Desktop\ModulesFirstNotVersioned\Modules2\Microsoft.PowerShell.PSResourceGet\1.1.0\PSGet.Format.ps1xml'. VERBOSE: Loading module from path 'C:\Users\olavb\Desktop\ModulesFirstNotVersioned\Modules2\Microsoft.PowerShell.PSResourceGet\1.1.0\Microsoft.PowerShell.PSResourceGet.psm1'. VERBOSE: Exporting function 'Import-PSGetRepository'. VERBOSE: Importing function 'Import-PSGetRepository'. VERBOSE: Loading module from path 'C:\Users\olavb\Desktop\ModulesFirstNotVersioned\Modules2\Microsoft.PowerShell.PSResourceGet\1.1.0\Microsoft.PowerShell.PSResourceGet.dll'. Import-Module: Could not load file or assembly 'Microsoft.PowerShell.PSResourceGet, Version=1.1.0.1, Culture=neutral, PublicKeyToken=null'. Assembly with same name is already loaded PS >
I also run into this frequently and I have no idea how to solve it.
> Import-Module Microsoft.Graph.Authentication -MaximumVersion 2.24.0 -Verbose -Debug VERBOSE: Loading module from path 'C:\Users\niccodan\AppData\Local\PowerShell\Modules\Microsoft.Graph.Authentication\2.24.0\Microsoft.Graph.Authentication.psd1'. VERBOSE: Loading 'FormatsToProcess' from path 'C:\Users\niccodan\AppData\Local\PowerShell\Modules\Microsoft.Graph.Authentication\2.24.0\Microsoft.Graph.Authentication.format.ps1xml'. VERBOSE: Populating RepositorySourceLocation property for module Microsoft.Graph.Authentication. VERBOSE: Loading module from path 'C:\Users\niccodan\AppData\Local\PowerShell\Modules\Microsoft.Graph.Authentication\2.24.0\Microsoft.Graph.Authentication.dll'. Import-Module: Could not load file or assembly 'Microsoft.Graph.Authentication, Version=2.24.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Assembly with same name is already loadedThe
.dllid loaded twice and the second time it displays an error.Trying to add some insight, this is my understanding:
Background:
PowerShell is supposed to be able to manage module versions side-by-side, loading the appropriate version as required.
However a fundamental limitation in the scheme is that PowerShell can't unload/reload .Net assemblies.This is problematic for versioned modules that depends on versioned assemblies like so
- 1.0.0\modulename.psd1 uses assemblyname.dll v1.0.0
- 1.0.1\modulename.psd1 uses assemblyname.dll v1.0.1
Because once the modulename +assembly is loaded at one version, there's no way to switch to a different version in that session, that's what
Assembly with same name is already loadedis saying.Import-Module version searching bug?
I think the Olav Rønnestad Birkeland (@o-l-a-v) has rightly identified that there is something defficent in the version searching / loading logic.
My suspicion is that for modules in versioned subfolders (e.g.
1.0.1\) PowerShell uses the folder name as quick indicator of the version whilst building a list of candidates.
However for modules that are not in a versioned folder it seems to actually load the module even before it's determined if its the appropraite version.
This then causes the problem when it later tries to load the actually desired version and hits an error because the previous version is already loaded.^ I'm hoping someone else can anaylse and confirm or disprove my suspcion.
Daniel Niccoli (@danielniccoli)
Note, whilst your error has similarities I suspect your error is just down to a bad/mixed install of Microsoft.Graph components.
Check your versions withGet-Module -ListAvailable Microsoft.Graph*and if they're inconsistent I'd suggest uninstall/deleting them and re-installing Microsoft.GraphReacted by Olav Rønnestad Birkeland


Prerequisites
Steps to reproduce
Microsoft.PowerShell.PSResourceGetv1.0.2.Using pwsh.exe v7.4.1
Microsoft.PowerShell.PSResourceGet' -RequiredVersion 1.0.2 -Verbose -DebugUsing VSCode
vscode-powershellextension v2024.0.0 and PowerShell v7.4.1Import-Module -Name 'Microsoft.PowerShell.PSResourceGet' -RequiredVersion 1.0.2 -Verbose -Debugin the PowerShell terminal inside VSCodeExpected behavior
Module should load without problems, without workarounds like having to modify PSModulePath in process context to put preferred module directory first.
Actual behavior
Error details
Environment data
Visuals
No response