$psEditor does not handle 32/64 bit file redirection

首先跟踪 $psEditor.Workspace.OpenFile 入口点，以及它如何将 Windows 路径传递给 VSCode。使用提供的 profile-path 示例重现 32/64-bit 重定向，然后将其与 sysnative workaround 进行比较。当有效的 64-bit 路径能够打开，且不会在无提示的情况下指向不存在的 sysWOW64 路径时，即表示完成。

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.