Visual StudioでLanguage Server Protocolがサポートされた

Visual Studio Codeのコーナーストーンは、Language Server Protocol (LSP)として知られるオープンスタンダードである。言語サーバーは、基本的に別プロセスでコンパイラ/アナライザが実行される。これはコンパイラーエラー報告、ホバーテキスト、コード補完（つまりインテリセンス）など、様々なタスクを処理する。

言語サーバーのコンセプトは新しいものではない: コード補完サポートはVimやEmacsのようなエディターで長年使われてきた。C#実装におけるこの概念の最初のメジャーな実装はOmniSharpとして知られている。この言語サーバーは、VS Code, Sublime, Atom, Emacs, Vim, Bracketsをサポートしている。

またVS Code言語サーバーはTypeScriptで開発された。OmniSharpとは違い、HTTPを使い、TypeScript言語サーバーは「サーバープロトコルとstdin/stdoutを通じて通信し、要求と応答にはV8デバッガープロトコルを使ったJSONペイロードを使っている」。

2つの言語サーバーがVS Codeに統合されている。Microsoftはそれらと将来の言語で共通の標準を開発する必要があると感じていた。これによりLanguage Server Protocolが開発された。

Language Server Protocolの基本メッセージフォーマットとしてJSON-RPCが使われている。簡単に言うとJSON-RPCはSOAPの軽量な代替である。SOAPと同様にトランスポート層を必要とせず、stdio, 名前付きパイプ, ソケットなどに対して同等に機能する

Visual Studio自身は、Language Server Protocolをネイティブにサポートしない。そのため、VS言語サービスとLSPクライアントとの通信にはアダプターが必要である。Microsoft DevLabsは、単にLanguage Server Protocol Clientという名前のクライアントを提供しているだけである。

また言語ごとの拡張も必要になる。Language Server Protocolサンプルgithubリポジトリは、開発方法を示している。

より複雑な例として、Adam Driscoll氏のVisual Studio Language Server Protocol extension for PowerShellを見ることができる。Driscoll氏によるその機能に関する説明では:

私は将来、LSPクライアントから言語がサポートされると信じています。Visual StudioとVisual Studio Codeの両方で共有される統合言語は、両方のツールでよい成果を上げてくれます。私たちはまだやることがあります。LSPはデバッグをサポートしていません。それは別のプロトコルです。LSP自身はVisual Studio内で完結していません。それに関するドキュメントにチャートがあります。VSでそれが利用可能になるまで時間がかかると見込んでいます。