Add host bitness selection from VSCode UI.

[daviwil]

As of the following pull request, PowerShell Editor Services now has both x86 and x64 hosts:

PowerShell/PowerShellEditorServices#92

We should add a setting in the VS Code extension so that the user can select their desired host bitness.

[rkeithhill]

While the actual support for 64bit and 32bit debug hosts will be in 0.4.0, we will require VSCode changes to support the "selection" of host via the VSCode UI. That support won't be in the upcoming 0.10.7 drop of VSCode. So the package.json update to support this will have to wait until the 0.5.0 drop (presumably by then VSCode will have UI support for this selection).

But we should still do this for 0.4.0:

We should add a setting in the VS Code extension so that the user can select their desired host bitness.

[daviwil]

👍

[daviwil]

I guess the only thing left to do here is have a setting for the language service so that it can launch the x86 host if that's what the user wants?

[rkeithhill]

One way to do this (and it is something I experimented with) is to modify the package.json initial configuration like so:

                "initialConfigurations": [
                    {
                        "name": "PowerShell",
                        "type": "PowerShell",
                        "request": "launch",
                        "program": "${file}",
                        "args": [],
                        "cwd": "${file}"
                    },
                    {
                        "name": "PowerShell x86",
                        "type": "PowerShell x86",
                        "request": "launch",
                        "program": "${file}",
                        "args": [],
                        "cwd": "${file}"
                    }
                ]

This has to be done for both debugger configurations. This will give you a choice of which debugger in the Debug viewlet's dropdown.

The problem I ran into is that when you initially select a debugger - either PowerShell or PowerShell x86 - the initially selected debugger in the dropdown didn't seem to be deterministic and not always the right one. We could go this route, as the mitigation is simple - just select the right debugger from the drop down. Thoughts?

[daviwil]

Yeah having the additional x86 configuration included in the 64-bit initialConfigurations list might be nice to simplify things for the user. For the x86 default configuration I think we'd still want the single configuration.

My question in this case is more about having a setting for the language service to be run with the x86 if necessary. I think this may be necessary for the editing experience in the cases where some module or configuration is only available in x86 mode.

[rkeithhill]

So the language service can cause modules to get imported to support completion text? If so, then yeah, users would need to specify which language service host to use (32-bit or 64-bit).

[daviwil]

Not sure if they get imported, but if a module exports commands they'll show up in completion lists. On my machine I have the Azure Service Fabric SDK installed which comes with a binary PowerShell module that's only available for 64-bit PowerShell. If I launch the x86 PowerShell console I don't get tab completion for their cmdlets but in the 64-bit console they get completed.

[daviwil]

I'm about to add the following setting:

                "powershell.developer.editorServicesHostArch": {
                    "type": "string",
                    "default": "Any",
                    "description": "Specifies the architecture to use for the PowerShell Editor Services host.  Possible values are 'Any' (use the OS's architecture) or 'x86' (force x86 architecture on 64-bit OS)."
                },

That seems like possibly the wrong way to do it, though. Would it be better to have this instead?

                "powershell.use32BitHost": {
                    "type": "boolean",
                    "default": "false",
                    "description": "If true, causes the 32-bit language service to be used on 64-bit Windows.  On 32-bit Windows this setting has no effect.  This setting does not affect the debugger which has its own architecture configuration."
                },

[rkeithhill]

I like the second better but perhaps it should be useX86Host instead? Right now the debuggers are referred to as PowerShell and PowerShell x86. Should we try to make the names somewhat consistent or no? The thing I note about PowerShell is that the 32-bit version is referred to as Windows PowerShell (x86) in the start menu.

[daviwil]

Sounds good, I'll go with that.

[daviwil]

Pretty sure this one is done now.