The Future of Languages in Visual Studio

TLDR; I implemented a Visual Studio Language Server Protocol extension for PowerShell. Check out the source code here. See it in action here.

Visual Studio Language Server Protocol extensions

Visual Studio language development is hard. There are so many aspects to a language that you need to consider and working with the Visual Studio SDK can be trying at times.

Me every time I work on a PoshTools bug

Released a couple days ago, the newest Preview version of Visual Studio 2017 and the Language Server Protocol Client Preview, allow you to develop languages the same way you develop them in Visual Studio Code: using the Language Server Protocol. This abstracts away some of the intricacies of working with the VS SDK.

Here’s an image I took from documentation for adding a LSP extension that explains the architecture of the LSP client in Visual Studio and VS Code.

language server protocol implementation

An Example Language Server Protocol extension in Visual Studio

Knowing a lot about the PowerShell Language Support in Visual Studio, I decided to give it a try to see if I could use the new LSP support a try. The PowerShell extension for VS Code already communicates via LSP to the PowerShell Editor Services library that is hosted within PowerShell. This meant that I should be able to use the exact same language server to expose PowerShell in VS with the new client code.

I followed the instructions in the documentation to create my extension. The resulting implementation code for the LSP extension is actually very, very minimal.

The first step is to locate the VS Code extension. I’m just looking in the VS Code extension folder for it. I then find the Start-EditorService.ps1 script to actually launch the PowerShell Editor Services.

Once, I had that script, the next order of business was to actually launch PowerShell and pass the correct arguments to it. The script expects a session path, a log path and some other information about the hosting application. I defined all of that as arguments to PowerShell.exe.

PowerShell Editor Services works by starting up a TCP server within PowerShell and then communicates back and forth to the editor of the port. The port that it’s listening on is written out to the session file that you define on the command line. This file contains a bunch other info and is formatted as JSON. After starting the editor services, I then can parse the JSON file and open a TCP client to the editor services running in PowerShell.

The Visual Studio Language Server Protocol Client expects a Connection object to be returned with an input\output stream. In this case I can return a NetworkStream from the TCP client that is connected to PSES in PowerShell.

The Result

The result is that I now have IntelliSense and static code analysis in Visual Studio via PowerShell Editor Services. This means that features like PSScriptAnalyzer support, which don’t even exist in PoshTools, now are available in Visual Studio. I’m extremely impressed with how easy this way.

The Future

I believe that the future of language support with come from LSP clients. A unified language service shared between Visual Studio and Visual Studio Code will have great results on both tools. We still have a ways to go. The LSP doesn’t support debugging. It’s a different protocol. The LSP itself isn’t even complete within Visual Studio. There’s a chart in the documentation about it. I anticipate it will take some time before this is completely available in VS.

Until then, PoshTools continues to be a good alternative for PowerShell developers using Visual Studio.

If you would like to see the full implementation of the PowerShell Language Server Protocol Client, visit this GitHub repository.

Leave a Reply