Skip to content

Convert Editor Services host to PowerShell module #256

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Jun 12, 2016

Conversation

daviwil
Copy link
Contributor

@daviwil daviwil commented Jun 11, 2016

This (unfortunately large) commit includes two important design changes to
the PowerShell Editor Services hosting model.

The first change is the conversion of the host process to be loaded as a
PowerShell module inside of powershell.exe. This change enables a lot of
interesting possibilities including the ability to run the Editor Services
host on a remote machine and connect to it from a client machine. Another
benefit of this approach is the ability to load assembly dependencies
based on the version of PowerShell in which the host is loaded.

Following on from the previous point, the second change is to introduce a
separate build of the PSES host which is compiled against the Nano Server
SDK. This enables the PSES host to be loaded in the edition of PowerShell
that is shipped with Nano Server.

Both of these changes bring us much closer to enabling a remote editing
experience which would allow someone to use VS Code on a Linux or OSX
machine and connect to an Editor Services host running in a Windows or
Nano Server VM. We will need to finish the WebSockets channel support
before this is fully possible, though.


This change is Reviewable

@rkeithhill
Copy link
Contributor

That's quite the PR. :-) What would be really cool is if this module could get loaded into a PowerShell process that could be used by VSCode as the "terminal".

I see that VSCode does define some env vars in the PowerShell process it creates for the terminal:

VSCODE_CWD                     C:\Program Files (x86)\Microsoft VS Code
VSCODE_IPC_HOOK                \\.\pipe\Code-61fe0e-sock
VSCODE_NLS_CONFIG              {"locale":"en-us","availableLanguages":{}}
VSCODE_PID                     13132
VSCODE_SHARED_IPC_HOOK         \\.\pipe\Code-61fe0e-shared-sock

I wonder if any of that could help with this?

@gerane
Copy link
Contributor

gerane commented Jun 12, 2016 via email

@daviwil
Copy link
Contributor Author

daviwil commented Jun 12, 2016

@rkeithhill yeah, I wasn't crazy about that one huge commit but it would have taken a while to break up the changes once I finally got everything working.

Regarding the use of this to have VS Code's terminal connect to it... I've been thinking about that. It's possible that once PSES has been loaded by the extension, I could invoke the terminal and have it run powershell.exe but launch a script which connects it to the language service's session so that you'd have a terminal which shares the same session. Not sure what the details of that will be yet, but my vague sense is that it's possible.

@daviwil daviwil force-pushed the daviwil/pses-as-module branch 5 times, most recently from a60454d to 2d08c11 Compare June 12, 2016 19:25
daviwil added 2 commits June 12, 2016 12:31
This (unfortunately large) commit includes two important design changes to
the PowerShell Editor Services hosting model.

The first change is the conversion of the host process to be loaded as a
PowerShell module inside of powershell.exe.  This change enables a lot of
interesting possibilities including the ability to run the Editor Services
host on a remote machine and connect to it from a client machine.  Another
benefit of this approach is the ability to load assembly dependencies
based on the version of PowerShell in which the host is loaded.

Following on from the previous point, the second change is to introduce a
separate build of the PSES host which is compiled against the Nano Server
SDK.  This enables the PSES host to be loaded in the edition of PowerShell
that is shipped with Nano Server.

Both of these changes bring us much closer to enabling a remote editing
experience which would allow someone to use VS Code on a Linux or OSX
machine and connect to an Editor Services host running in a Windows or
Nano Server VM.  We will need to finish the WebSockets channel support
before this is fully possible, though.
This change introduces a separate PowerShellEditorServices.NoNano.sln
solution file so that AppVeyor will not build the Nano Server version of
the project.  This is a temporary measure until we get a build image with
the Nano Server SDK baked in.  After that we will take this solution file
back out so that the Nano Server version gets built by AppVeyor.
@daviwil daviwil force-pushed the daviwil/pses-as-module branch from 2d08c11 to 474708c Compare June 12, 2016 19:31
daviwil added a commit to PowerShell/vscode-powershell that referenced this pull request Jun 12, 2016
This change refactors the existing PowerShell Editor Services host
management and editor client code to use the PSES host as a PowerShell
module rather than its previous executable form.  This involves launching
the powershell.exe process and loading up the PSES host as a module in
that process.  It also involves communicating with the PSES host via named
pipes instead of standard in/out as we did previously.

This change can be understood further by looking at the following pull
request at the PowerShellEditorServices repo:

PowerShell/PowerShellEditorServices#256
daviwil added a commit to PowerShell/vscode-powershell that referenced this pull request Jun 12, 2016
This change refactors the existing PowerShell Editor Services host
management and editor client code to use the PSES host as a PowerShell
module rather than its previous executable form.  This involves launching
the powershell.exe process and loading up the PSES host as a module in
that process.  It also involves communicating with the PSES host via named
pipes instead of standard in/out as we did previously.

This change can be understood further by looking at the following pull
request at the PowerShellEditorServices repo:

PowerShell/PowerShellEditorServices#256
daviwil added a commit to PowerShell/vscode-powershell that referenced this pull request Jun 12, 2016
This change refactors the existing PowerShell Editor Services host
management and editor client code to use the PSES host as a PowerShell
module rather than its previous executable form.  This involves launching
the powershell.exe process and loading up the PSES host as a module in
that process.  It also involves communicating with the PSES host via named
pipes instead of standard in/out as we did previously.

This change can be understood further by looking at the following pull
request at the PowerShellEditorServices repo:

PowerShell/PowerShellEditorServices#256
daviwil added a commit to PowerShell/vscode-powershell that referenced this pull request Jun 12, 2016
This change refactors the existing PowerShell Editor Services host
management and editor client code to use the PSES host as a PowerShell
module rather than its previous executable form.  This involves launching
the powershell.exe process and loading up the PSES host as a module in
that process.  It also involves communicating with the PSES host via named
pipes instead of standard in/out as we did previously.

This change can be understood further by looking at the following pull
request at the PowerShellEditorServices repo:

PowerShell/PowerShellEditorServices#256
@daviwil daviwil merged commit 9a10287 into master Jun 12, 2016
@daviwil daviwil deleted the daviwil/pses-as-module branch June 12, 2016 21:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants