$psEditor does not handle 32/64 bit file redirection

[gerane]

PSES is properly running in a 64bit context, but when it passes a path to be opened in VSCode it is being redirected to the 32bit path.

Example:

Register-EditorCommand `
    -Name 'PowerShellEditorServices.OpenAllUserEditorProfile' `
    -DisplayName 'Open All User Editor Profile' `
    -SuppressOutput `
    -ScriptBlock {
        param([Microsoft.PowerShell.EditorServices.Extensions.EditorContext]$context)

        $ProfilePath = Join-Path -Path $PShome -ChildPath 'Microsoft.VSCode_profile.ps1'
        If (!(Test-Path -Path $ProfilePath)) { New-Item -Path $ProfilePath -ItemType File }

        $psEditor.Workspace.OpenFile($ProfilePath)
    }

The Editor Command properly creates

"C:\Windows\System32\WindowsPowerShell\v1.0\Microsoft.VSCode_profile.ps1"

Then when the same path is passed to $psEditor.Workspace.OpenFile and it is passing it to VSCode to open, Code is not handling the 32/64 redirect. This has terrible consequences for the user.

Code the attempts to open the following path:

"C:\Windows\sysWOW64\WindowsPowerShell\v1.0\Microsoft.VSCode_profile.ps1"

The command silently fails because the item does not exist.

As a temporary workaround you could pass $psEditor this path and it will work:

"C:\Windows\sysnative\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1"

This is not really a good solution and really should be addressed by VSCode. If they never plan on making a 64 bit client, they need to be handling 32/64 redirect. However, since I really don't think that will happen(or if it does, its likely not anytime soon), maybe we can get PSES handling this by passing the sysnative path if PSES is running in a 64 bit context.

[daviwil]

Thanks for filing this. We'll have to look into the right way to accomplish this which works across any of the editors that consume PSES regardless of what bitness they have.