Using enableProfileLoading to modify PSModulePath does not persist.

[LethiferousMoose]

Issue Description

If I enable profile loading and in a profile put the line
$Env:PSModulePath = $Env:PSModulePath + ';<CUSTOM_PATH>' and launch VS Code, after the integrated terminal loads, the new path does not exist and C:\Users\<User>\.vscode\extensions\ms-vscode.powershell-1.5.1\modules is missing. Note that other environment variables I set still exist.

Environment Information

Visual Studio Code

Name	Version
Operating System	Windows_NT x64 10.0.15063
VSCode	1.18.1
PowerShell Extension Version	1.5.1

PowerShell Information

Name	Value
PSVersion	6.0.0-rc
PSEdition	Core
GitCommitId	v6.0.0-rc
OS	Microsoft Windows 10.0.15063
Platform	Win32NT
PSCompatibleVersions	1.0 2.0 3.0 4.0 5.0 5.1.10032.0 6.0.0-rc
PSRemotingProtocolVersion	2.3
SerializationVersion	1.1.0.1
WSManStackVersion	3.0

Visual Studio Code Extensions

Visual Studio Code Extensions(Click to Expand)

Extension	Author	Version
code-spell-checker	streetsidesoftware	1.5.1
markdown-all-in-one	yzhang	0.11.2
mssql	ms-mssql	1.2.1
PowerShell	ms-vscode	1.5.1
vscode-eslint	dbaeumer	1.4.3
xml	DotJoshJohnson	1.9.2

[TylerLeonhardt]

Hi there, thanks for this! Can you tell me which profile you're adding this line to?

I believe (@rkeithhill + @daviwil please correct me if I'm wrong), the extension only loads:

$PROFILE.AllUsersAllHosts
and
$PROFILE.CurrentUserAllHosts

if you specify enableProfileLoading. Can you make sure that you're adding that line to one of these profiles?

[rkeithhill]

It should also load the CurrentHost versions - Microsoft.VSCode_profile.ps1 e.g.:

2:147ms> $profile | fl * -force

AllUsersAllHosts       : C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1
AllUsersCurrentHost    : C:\Windows\System32\WindowsPowerShell\v1.0\Microsoft.VSCode_profile.ps1
CurrentUserAllHosts    : C:\Users\Keith\Documents\WindowsPowerShell\profile.ps1
CurrentUserCurrentHost : C:\Users\Keith\Documents\WindowsPowerShell\Microsoft.VSCode_profile.ps1
Length          

And I can't repro this. If I put the following into the CurrentUserCurrentHost profile:

Write-Warning "Executing $($MyInvocation.MyCommand.Name)"
$env:PSModulePath = $env:PSModulePath + ";c:\ModulePath"

and then restart my session, I get this:

PowerShell Integrated Console

WARNING: Executing Microsoft.VSCode_profile.ps1
[master ≡] ~\GitHub\psake\psake
1:338ms>  $env:PSModulePath -split ';'
C:\Users\Keith\Documents\WindowsPowerShell\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\
C:\Program Files (x86)\Microsoft SQL Server\130\Tools\PowerShell\Modules\
C:\Users\Keith\.vscode\extensions\ms-vscode.powershell-1.5.1\modules
c:\ModulePath

However the bit about the extension's modification to the path being missing is troubling. Which profile are you putting the PSModulePath modification in?

The Start-EditorServices PowerShell command does modify process-level PSModulePath env var.

vscode-powershell/scripts/Start-EditorServices.ps1

Lines 185 to 188 in 93bc21c

	# Add BundledModulesPath to $env:PSModulePath
	if ($BundledModulesPath) {
	$env:PSModulePath = $env:PSModulePath + [System.IO.Path]::PathSeparator + $BundledModulesPath
	}

I wonder if one of your profiles is accidentally whacking PSModulePath to its default?? Could you dump the contents of the four profiles listed above and see what modifications are being made to $env:PSModulePath?

[rkeithhill]

BTW one of the things I'd like to see is an init script for your workspace so that you could import just the modules needed to drive auto-completion for that workspace. Something like .vscode\psic-init.ps1.

[LethiferousMoose]

@rkeithhill I am using the Microsoft.VSCode_profile.ps1 file you mentioned, in the .../Documents/PowerShell/ directory. Also I did narrow down the issue cause. It only blows away the path when the directory I append to the PSModulePath is the same as the VS Code workspace. i.e. $Env:PSModulePath = $Env:PSModulePath + ';C:\dev\<VS Code Workspace>', if I tell it a different directory, the .vscode directory persists as does my change. It's very odd. I have so far only tested this with the latest version of 6.0 Core, so I do not know if the same is true for 5.1.

Using current workspace in profile gives me a path like this (using C:\dev\workspace in profile):

C:\Users\1020216\Documents\PowerShell\Modules;C:\Program Files\PowerShell\Modules;c:\program files\powershell\6.0.0-rc\Modules

Using a different folder that is not my workspace gives me something like this (using C:\dev in profile):

C:\Users\1020216\Documents\PowerShell\Modules;C:\Program Files\PowerShell\Modules;c:\program files\powershell\6.0.0-rc\Modules;C:\Users\1020216\.vscode\extensions\ms-vscode.powershell-1.5.1\modules;C:\dev

Let me know if you need anymore details.

Is that init script something that has been discussed? Because I could see that being fairly useful.

[rkeithhill]

Are you sure you modifying the profile in Documents\PowerShell instead of the one in Documents\WindowsPowerShell? I can't repro this with PS Core 6.0.0-rc.

BTW, init script has been discussed here #190 and #880.

[LethiferousMoose]

Yes I am modifying the correct file. I am going to do some more testing on my end. It looks like it might be related to my workspace in particular, perhaps it's related to some setting or something with Git.

[LethiferousMoose]

Well I have no idea what is going on. If I copy my entire directory tree to a new location and open the workspace on the copy, the issue does not happen. But if I put a new copy in the same root folder the issue shows up, only in this one folder does it happen. If I move it one folder higher or one deeper the issue does not happen....

For example C:\dev\MyRepos\ breaks, C:\dev\ works and C:\dev\MyRepos\Test works. Anything checked out into C:\dev\MyRepos\ and opened in VS Code causes this issue to occur if the profile changes the PSModulePath to contain that directory. If I change "MyRepos" to a different name the issue also goes away. One final note, not surprisingly this is also unique to a single machine, copying the same directory structure to a new computer does not reproduce the issue.

Let me know if there is any thing you'd like to me do before I purge/rename the existing folder to make the issues go away.

[rkeithhill]

Is that directory a junction/mount point or anything else weird like that? The other thing that would be good to know is if this happens in pure PowerShell Core - no VSCode.

[LethiferousMoose]

Nothing special about it that I can think of. It's just a folder I created to check out repos from my Stash/Bitbucket Server profile. The only thing "different" about it is that it contains Git checkouts. Do you mean using a regular non-VSCode PowerShell profile? It works fine, that's how I've been able to use my modules in PowerShell Core.

[LethiferousMoose]

@rkeithhill Good news! I discovered how to reproduce the issue. This only occurs if you have a User/System Environment Variable defined for PSModulePath. I had done this for PowerShell 5.1.

I have a User Environment Variable defined for PSModulePath = C:\dev\MyRepos\Workspace via Advanced system settings -> Environment Variables, and then have an entry in the Microsoft.VSCode_profile.ps1 for $Env:PSModulePath = $Env:PSModulePath + ';C:\dev\MyRepos\Workspace'. I have tested this on a new machine and the issue is repeatable.

Whether or not this is a good idea is debatable... and it is still odd that it only seems to effect the Integrated Console.

[TylerLeonhardt]

Fascinating... did you ever try this in the ISE to see what happens?

[LethiferousMoose]

Doesn't the ISE only work with Windows PowerShell? This bug only shows up with the integrated console with PowerShell Core.

[TylerLeonhardt]

Ah yes. My bad. You said

This only occurs if you have a User/System Environment Variable defined for PSModulePath. I had done this for PowerShell 5.1.

and thought the issue was with 5.1. :)

So when you remove that User/System Environment Variable the issue disappears?

[rkeithhill]

Something weird going on indeed. AFAICT, PS Core doesn't reflect the PSModulePath change I made to my USER PATH env var. I instrumented my PS Core MS.VSCode profile to display PSModulePath before and after and it looks like everything is fine:

PowerShell Integrated Console

WARNING: Executing Microsoft.VSCode_profile.ps1
WARNING: PSModulePath before - C:\Users\Keith\Documents\PowerShell\Modules;C:\Program Files\PowerShell\Modules;c:\program files\powershell\6.0.0-rc\Modules;C:\Users\Keith\.vscode\extensions\ms-vscode.powershell-1.5.1\modules
WARNING: PSModulePath after - C:\Users\Keith\Documents\PowerShell\Modules;C:\Program Files\PowerShell\Modules;c:\program files\powershell\6.0.0-rc\Modules;C:\Users\Keith\.vscode\extensions\ms-vscode.powershell-1.5.1\modules;C:\tmp\workspace

But when I inspect the final PSModulePath, two paths are missing:

PS C:\tmp\workspace> $env:PSModulePath -split ';'
C:\Users\Keith\Documents\PowerShell\Modules
C:\Program Files\PowerShell\Modules
c:\program files\powershell\6.0.0-rc\Modules

Hmm, time to look into this some more.

[LethiferousMoose]

@tylerl0706 Yes, removing the pre-set variable fixes the issue after you restart the console.

@rkeithhill Yes, I was seeing the same thing, the profile has the correct value, but somewhere between there and the console fully loading the value gets defaulted back the original value. Also since PowerShell Core does not load the windows PSModulePath, I find it very strange that a system/user variable that Core is ignoring correctly (which we can see in the profile output) is somehow interfering with the integrated console and causing it to reset the value of the variable.

[rkeithhill]

OK this might be caused by PS Core:

if (!string.IsNullOrEmpty(currentProcessModulePath) &&
    NeedToClearProcessModulePath(currentProcessModulePath, personalModulePath, sharedModulePath, runningSxS))
{
    // Clear the current process module path in the following cases
    //  - start sxs ps on windows [machine-wide env:PSModulePath will influence]
    //  - start sxs ps from full ps
    //  - start sxs ps from inbox nano/iot ps
    //  - start full ps from sxs ps
    //  - start inbox nano/iot ps from sxs ps
    currentProcessModulePath = null;
}

You don't normally see this problem in PS Core but with the VSCode extension, PS Core is started, a script is run to import and start PSES. At this point the env var is correct. However,once PSES starts executing it has to set up its PSHost UI and I "think" in the process of doing that, the above code is executed which resets the PSModulePath. I haven't had a chance to verify this yet in the debugger. It's a theory at this point. If this is the case, perhaps we can stash and restore the PSModulePath in PSES.

[JustinGrote]

@SydneyhSmith @TylerLeonhardt I wasn't able to reproduce per #1122 (comment)

1. Set PSMODULEPATH user environment variable
2. Add following to Microsoft.VSCode_profile.ps1 including the path of my folder workspace

write-host -fore yellow "Before: $ENV:PSMODULEPATH"
$ENV:PSMODULEPATH = $ENV:PSMODULEPATH + ';C:\Users\JGrote\Desktop'
write-host -fore green "After: $ENV:PSMODULEPATH"