-
Notifications
You must be signed in to change notification settings - Fork 235
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
Conversation
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:
I wonder if any of that could help with this? |
If you imported the module in integrated terminal, would it be able to
communicate with the editor?
Very interesting idea though Keith. I like where this is headed.
Great job David!
|
@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. |
a60454d
to
2d08c11
Compare
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.
2d08c11
to
474708c
Compare
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
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
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
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
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