$env:PSModulePath Question / Potential Issue

[GHRoss]

I'm having an issue with Intellisense being very slow.

I've managed to whittle it down to VS Code loading modules over the network, so every time I hit tab, it goes off to the network share and does what it needs to do and then Intellisense works.

This can be up to 2 minutes at a time, however.

I removed the entry from $env:PSModulePath in the integrated VS Code terminal, fine, Intellisense is once again rapid and I can continue happily with my work, then around 30 seconds or so later, everything slows down again.

Lo and behold, the UNC of the file share is back in $env:PSModulePath! I've tested this in the ISE and do not get the same issue after removing the UNC share path.

Happy to submit logs if required, hoping there's just something I'm missing, however.

EDIT: It seems to be that when I hit tab or Intellisense trys to fire, it adds the UNC share path back to my $env:PSModulePath. Again tried with the ISE and don't get the same thing, so I believe this to be a bug.

SECOND EDIT: It appears to add the path back into $env:PSModulePath as soon as you click into the editor window.

[TylerLeonhardt]

fascinating... sounds like a bug... Thanks for the report! Where does it get the file share path from? Are you adding that to the PSModulePath in your profile or something?

It'd be helpful if you could share the logs.

[GHRoss]

@tylerl0706 I'm not sure where it gets the file share path from.

I took everything out of my profile to eliminate that as an issue.

I don't like to assume, but I think as we have our documents redirected, it's using that location instead of the normal C:\Users\User.Name\WindowsPowerShell\Modules location.

I've moved all of the modules in there to C:\Program Files\WindowsPowerShell\Modules, and the speed is back to normal.

[TylerLeonhardt]

Glad to see you're at least unblocked. Seems like a bug. We'll take a look.

[Cirzen]

This is becoming a pain for me too. I have a number of module paths being inserted via my profile, and they seem to be overwritten whenever the script analyzer starts up. It's a piece of cake to replicate - is there anything I can provide to help with this?

[ajklotz]

Any updates?

[rjmholt]

This is caused by an underlying issue within PowerShell: PowerShell/PowerShell#9921. I had hoped it would be fixed in PS 7, but unfortunately PS 7 still mutates the module path when new runspaces are opened.

Some approaches we can try:

• Save and re-set the module path around PSSA invocations
• Work with PSSA to allow runspace pools to be provided or disabled

[o-l-a-v]

This seems to still be a problem? VSCode v1.92.2, extension v2024.2.2, PowerShell v7.4.5.

In my profile I change the order of PSModulePath in process context. It works great in standalone PowerShell consoles, in Windows Terminal, and I've verified with output that the profile runs successfully when VSCode and the extension starts up.

But right after when I write $env:PSModulePath.Split(';') in the integrated terminal using "PowerShell Extension", the PSModulePath in process context has been reset to default.

Related issues:

• 2017-12-09 Using enableProfileLoading to modify PSModulePath does not persist. #1122
• 2019-06-04 PSModulePath mutated during script changes #2008
• 2019-08-08 Removals from $ENV:PSModulePath are not respected. #2127

This causes conflicting assemblies when trying to load a PowerShell module thats also included with PowerShell, like Microsoft.PowerShell.PSResourceGet. Related issues:

• 2022-04-10 Extension preloads DLLs even tho the modules are not used #3912
• 2024-02-08 Can't import v1.0.2 to pwsh.exe v7.4.1 with error "Import-Module: Assembly with same name is already loaded" PowerShell#21201
• 2024-02-08 PowerShell included modules does not have a version directory like Windows PowerShell had PowerShell#21199