拡張機能を導入しただけでは今までのWindows上での開発と同じです。Windowを開きます。続いて、プロジェクトルートを開きます。Codeの左下に、下図に示すようなWSLの表記があれば、正しくRemote-WSL環境が構築され有効になっていることを意味します。答えは、(私の知る範囲では)イエスです。Codeには2つの選択肢があります。Serverに接続する方法とローカルで完結する方法です。したがって、私達は常に適切な方を選ばなければなりません。一方で、それはRemote-WSL環境を構築しても、Windows環境のみで開発を行う自由があることを意味します。(同一プロジェクトで2つの環境を混在させるのは不適切だと思いますが、プロジェクトごとに使い分けられるということです。)ちなみに、一度開いたWSLのプロジェクトは下図のように表示されます。先頭が同じなので少し不便な表記ですが、二度目以降はもっと簡単にRemote-WSLの画面を開くことができます。Serverという2つに分割されたことにより、拡張機能(extension)はそれが動く場所に基づいて2種類に分類されます。INSTALLEDに表示されます。多くの拡張機能は後者に分類されます。Serverの役割だからです。拡張機能は通常、インストール時に正しい場所へ配置されるので、普通、この違いをユーザーが意識する必要はありません。Serverの2つに分かれていることで、このような違いが生じたということを知っておくことは重要です。まとめRemote-WSLはWindows上での開発から多くの環境依存の問題を取り除くことが期待されています。表面上は今までの開発とほとんど変わらずにです。WindowsへのLinux環境の自然な導入です。これは素晴らしいことだと思いませんか。Codeのユーザーなら試してみてください。現在利用可能なWSLはあくまでLinuxのエミュレータです。したがって、いくつかの制限があります。ファイルシステムに関してはWindowsとLinuxの標準的なファイルシステムが異なるため、大きなオーバーヘッドが生じています。(外部パッケージのインストールなどでは大量のファイルを書き込むので、この問題が顕著に現れます。)しかし、Microsoftは本物のLinuxカーネルをWindows上で動かせるようにするWSL2を開発中で、これを利用することでI/Oの高速化やいくつかの問題の解決が期待されます。Insidersでのみ利用可能です。先の話ですが、WSL2が利用可能になれば、Remote-WSLを用いた開発はより快適になるでしょう。記事一覧へコメントフォームは設置していませんので、ご意見・ご感想などはTwitter(@cosnomi)などへお願いします。