Plan for packaging of the x86/x64 host EXE and CMD files

[rkeithhill]

What is the plan for allowing a user to choose between the x86 and x64 host? I was expecting to see two debugger configurations in the package.json file: “PowerShell x86” and “PowerShell x64”.

I’m not sure which should be the default (probably the x64 host). Anyway, I was thinking about changing the package.json file but I realize I’m not sure how the two EXE and CMD files will be placed in the extension's install dir. The exe’s have different names so they could be co-located in the Bin dir but the CMD files have the same name. Is this a case where the x86 CMD should have x86 put in its filename so it can be co-located in the Bin dir?

Thoughts?

[adamdriscoll]

Different CMD names is probably a good idea. The x64 host is technically AnyCPU so if we default to that it would run on x86 as well.

[daviwil]

Yep, agree with both your points. We'll need a separate .cmd to run the x86 host and then have a separate debugger configuration for that. x64 should be the default, and like Adam says, it should work fine on 32-bit systems.

I was thinking about adding a new preference setting in the VS Code extension to choose which bitness to use for the language service. It kinda sucks to have to change the bitness setting in two different places but maybe later we can find a clever way to make one setting that controls both.

Feel free to go for it, Keith!

[rkeithhill]

I'm looking at this - trying to understand the debuggers section of the package.json format. Ideally, I would prefer that users did not have to change a user preference setting to select the host. It would be cool if it were something that could be selected via the debug target dropdown in the Debugger viewlet's toolbar. But I'm not quite seeing how to do that with the package.json file. :-(

I created two different debuggers: entries (it's set up to take an array) but when you click the gear icon in the Debugger toolbar to create a new launch.json file, PowerShell no longer shows up in the list. So while the format seems to indicate it will take an array of debugger configurations, it isn't working for me (or more likely I'm doing something wrong).

Anyway, I filed on issue on the VSCode repo. microsoft/vscode#1696

[rkeithhill]

BTW what does it look like to "launch" a remote host debug adapter? Do we need to be able to specify x86 for that as well? I would think so.

[daviwil]

You may need to define a second debugger type called PowerShellx86 in the "debuggers" contribution in package.json, but I'm not sure. Hopefully the VS Code team can tell us something on the bug you filed. Great description of the problem, by the way!

For remote debugging, VS Code's debug adapter API also allows you to specify a debug server with IP address and port. This may only be available for the attach action (as opposed to launch) but I haven't tried it yet. Search this page for 'attach' and check out the section about attaching to the Mono debugger. We may be able to have a "debugger gateway" server running on a remote machine that, upon client connection, will launch the necessary host with desired bitness and then proxy requests through the gateway to the remote machine's locally-running host.

If we're going to allow web-based editing/debugging of PowerShell scripts in the future, we'll probably have to solve this problem generally for both language and debug services. It could make sense to add a "gateway mode" to Microsoft.PowerShell.EditorServices.Host.exe which can provide this remote server capability in a general way.

Great timing to start discussing this since WebSocket connections just became a reality :)

[daviwil]

Hey Keith, where did you end up with adding a x86/x64 setting to allow use of the x86 host? I know we're still waiting for a more official solution from the VS Code team, but I'm wondering if we can set up two debugger configurations in our extension in the short term until they get something worked out.

I'm going to try and finish up the 0.4.0 work this week and release on Monday the 8th. If you're booked and won't have time to get around to it, let me know and I'll be happy to finish it up. Thanks again for looking into this!

[rkeithhill]

I have time this week. I just didn't want to check anything in until I had an insiders drop to verify the checked in code works. I've been holding off on the SortText fix and the ${file} tweak until then.

I can do this change as well but I wanted to see exactly how they planned on supporting this scenario. The last comment (microsoft/vscode#1696) indicated defining additional x86/x64 debuggers. Assuming that is what makes it into the Feb drop, that should be very straight forward to implement.

[daviwil]

Ahhh, yeah. When they said they'd add it in the February release, I was considering that to be the one after the upcoming one. Since it's February on Monday I wonder if they meant it'll be in the next :)

Your plan makes sense, sounds good to me!

[daviwil]

I think we're good on this one now, right? Wanna close it, Keith?

[rkeithhill]

Yup.