WSLでの開発
Visual Studio Code WSL 拡張機能を使用すると、Windows Subsystem for Linux (WSL) を VS Code から直接、常時開発環境として使用できます。Windowsから快適に、Linuxベースの環境で開発し、Linux固有のツールチェーンとユーティリティを使用し、Linuxベースのアプリケーションを実行およびデバッグできます。
この拡張機能は、WSL内で直接コマンドやその他の拡張機能を実行するため、パスに関する問題、バイナリの互換性、その他のクロスOSの課題を心配することなく、WSLまたはマウントされたWindowsファイルシステム (例: /mnt/c
) にあるファイルを編集できます。この拡張機能は、VS Code ServerをWSL内にインストールします。サーバーは、WSL内の既存のVS Codeインストールとは独立しています。
これにより、VS Codeは、コードがどこにホストされていても、完全なIntelliSense (入力候補)、コードナビゲーション、デバッグを含む、ローカル環境と同等の開発エクスペリエンスを提供できます。
はじめに
注: このトピックを確認した後、入門用のWSLチュートリアルから始めることができます。
インストール
始めるには、以下を行う必要があります。
-
任意のLinuxディストリビューションとともにWindows Subsystem for Linuxをインストールします。
注: WSL 1には、特定の種類の開発において既知の制限事項があります。また、Alpine Linuxにインストールされた拡張機能は、拡張機能内のネイティブソースコードにおける
glibc
の依存関係が原因で機能しない場合があります。詳細については、リモート開発とLinuxの記事を参照してください。 -
Visual Studio Codeを**Windows**側 (WSL内ではない) にインストールします。
注: インストール中に**追加タスクの選択**を求められたら、`code`コマンドを使用してWSLでフォルダーを簡単に開けるように、**PATHに追加**オプションにチェックを入れるようにしてください。
-
WSL拡張機能をインストールします。VS Codeで他のリモート拡張機能を使用する予定がある場合は、Remote Development 拡張機能パックをインストールすることもできます。
リモートフォルダーまたはワークスペースを開く
WSLターミナルから
Windows Subsystem for Linux内のフォルダーをVS Codeで開く方法は、コマンドプロンプトまたはPowerShellからWindowsフォルダーを開く方法と非常によく似ています。
-
**WSLターミナルウィンドウ**を開きます (スタートメニュー項目を使用するか、コマンドプロンプト/PowerShellから`wsl`と入力)。
-
VS Codeで開きたいフォルダーに移動します (Windowsファイルシステムのマウント先、例えば
/mnt/c
を含むが、これに限定されない)。 -
ターミナルで**`code .`**と入力します。これを初めて実行する場合、VS CodeがWSLで実行するために必要なコンポーネントを取得する様子が表示されるはずです。これは短時間で完了し、1回だけ必要です。
注: このコマンドが機能しない場合は、ターミナルを再起動する必要があるか、VS Codeをインストールしたときにパスに追加しなかった可能性があります。
-
しばらくすると、新しいVS Codeウィンドウが表示され、VS CodeがWSLでフォルダーを開いているという通知が表示されます。
VS CodeはWSLでの自己設定を続け、進捗状況を最新の状態に保ちます。
-
完了すると、左下隅にWSLインジケーターが表示され、通常どおりVS Codeを使用できるようになります。
これで完了です!このウィンドウで実行するすべてのVS Code操作は、編集やファイル操作から、デバッグ、ターミナルの使用まで、WSL環境で実行されます。
VS Codeから
または、VS Codeから直接WSLウィンドウを開くこともできます
- VS Codeを起動します。
- F1キーを押し、既定のディストリビューションの場合は**WSL: WSLに接続**を、特定のディストリビューションの場合は**WSL: ディストリビューションを使用してWSLに接続**を選択します。
- [ファイル]メニューを使用してフォルダーを開きます。
すでにフォルダーが開いている場合は、**WSL: WSLでフォルダーを再度開く**コマンドを使用することもできます。どのディストリビューションを使用するかを尋ねられます。
WSLウィンドウで現在の入力をローカルウィンドウで開きたい場合は、**WSL: Windowsで再度開く**を使用します。
Windowsコマンドプロンプトから
Windowsプロンプトから直接WSLウィンドウを開くには、`--remote`コマンドラインパラメーターを使用します。
code --remote wsl+<ディストリビューション名> <WSL内のパス>
例: code --remote wsl+Ubuntu /home/jim/projects/c
入力パスがファイルかフォルダーかについては、ある程度推測する必要があります。ファイル拡張子がある場合、それはファイルと見なされます。
フォルダーを開くことを強制するには、パスにスラッシュを追加するか、以下を使用します
code --folder-uri vscode-remote://wsl+Ubuntu/home/ubuntu/folder.with.dot
ファイルを強制的に開くには、`--goto`を追加するか、以下を使用します
code --file-uri vscode-remote://wsl+Ubuntu/home/ubuntu/fileWithoutExtension
Gitの操作
WSLとWindowsで同じリポジトリを操作する場合は、行末が統一されていることを確認してください。詳細については、ヒントとテクニックを参照してください。
WSLでWindows Git資格情報マネージャーを使用するように構成することで、パスワードを回避することもできます。詳細については、ヒントとテクニックを参照してください。
拡張機能の管理
VS Codeは拡張機能を2つの場所のいずれかで実行します: ローカルのUI/クライアント側、またはWSL内です。テーマやスニペットのようにVS Code UIに影響を与える拡張機能はローカルにインストールされますが、ほとんどの拡張機能はWSL内に置かれます。
拡張機能ビューから拡張機能をインストールすると、自動的に正しい場所にインストールされます。インストールされると、カテゴリのグループ分けに基づいて拡張機能がどこにインストールされたかを判別できます。[ローカル - インストール済み] カテゴリとWSL用のカテゴリがあります。
注: 拡張機能の作成者で、拡張機能が正しく動作しない、または間違った場所にインストールされる場合は、詳細についてリモート開発のサポートを参照してください。
実際にリモートで実行する必要があるローカル拡張機能は、[ローカル - インストール済み] カテゴリで薄暗く表示され、無効になります。リモートホストに拡張機能をインストールするには、[インストール] を選択します。
また、拡張機能ビューに移動し、[ローカル - インストール済み] タイトルバーの右側にあるクラウドボタンを使用して[WSLにローカル拡張機能をインストール: {名前}] を選択することで、ローカルにインストールされているすべての拡張機能をWSL内にインストールすることもできます。これにより、WSLインスタンスにインストールするローカルにインストールされた拡張機能を選択できるドロップダウンが表示されます。
WSLでターミナルを開く
VS CodeからWSLでターミナルを開くのは簡単です。WSLでフォルダーが開かれると、VS Codeで開く**任意のターミナルウィンドウ** ([**ターミナル**] > [**新しいターミナル**]) は、ローカルではなく自動的にWSLで実行されます。
同じターミナルウィンドウから`code`コマンドラインを使用して、WSLで新しいファイルやフォルダーを開くなど、多くの操作を実行することもできます。`code --help`と入力すると、コマンドラインから利用できるオプションを確認できます。
WSLでデバッグする
WSLでフォルダーを開いた後、VS Codeのデバッガーは、アプリケーションをローカルで実行する場合と同じように使用できます。たとえば、`launch.json`で起動構成を選択し、デバッグを開始する (F5) と、アプリケーションはリモートホストで起動し、デバッガーがそれにアタッチされます。
.vscode/launch.json
でのVS Codeのデバッグ機能の設定に関する詳細については、デバッグのドキュメントを参照してください。
WSL固有の設定
VS Codeのローカルユーザー設定も、WSLでフォルダーを開いたときに再利用されます。これによりユーザーエクスペリエンスは一貫性が保たれますが、ローカルマシンとWSLの間でこれらの設定の一部を変更したい場合があります。幸いなことに、WSLに接続すると、コマンドパレット (F1) から[**設定: リモート設定を開く**] コマンドを実行するか、設定エディターの[**リモート**] タブを選択することで、WSL固有の設定も設定できます。これらは、WSLでフォルダーを開くたびに、既存のローカル設定を上書きします。
詳細: 環境セットアップスクリプト
WSLでVS Code Remoteを起動する場合、シェルの起動スクリプトは実行されません。これは、シェル用に調整された起動スクリプトに関する問題を回避するために行われました。追加のコマンドを実行したり、環境を変更したりする場合は、セットアップスクリプト`~/.vscode-server/server-env-setup` (Insiders版: `~/.vscode-server-insiders/server-env-setup`) で行うことができます。このスクリプトが存在する場合、サーバーが起動する前に処理されます。
このスクリプトは有効なBourneシェルスクリプトである必要があります。無効なスクリプトはサーバーの起動を妨げる可能性があることに注意してください。サーバーの起動を妨げるスクリプトになってしまった場合は、通常のWSLシェルを使用してセットアップスクリプトを削除または名前変更する必要があります。
出力とエラーについては、WSLログ ([**WSL: ログを表示**]) を確認してください。
詳細: WSL 2フォルダーをコンテナーで開く
WSL 2とDocker DesktopのWSL 2バックエンドを使用している場合、Dev Containers拡張機能を使用して、WSL内に保存されているソースコードを操作できます。以下の手順に従ってください。
-
まだの場合は、Docker DesktopのWSL 2サポートをインストールして設定します。
ヒント: [**設定**] > [**リソース**] > [**WSL統合**] に移動し、使用するWSLディストリビューションとのDocker統合を有効にします。
-
まだの場合は、WSL拡張機能とともにDev Containers拡張機能をインストールします。
-
次に、通常どおりWSLでソースコードフォルダーを開きます。
-
WSLでフォルダーが開いたら、コマンドパレット (F1) から**Dev Containers: コンテナーで再度開く**を選択します。
-
フォルダーに
.devcontainer/devcontainer.json
ファイルがない場合は、フィルター可能なリストから開始点を選択するか、既存のDockerfileまたはDocker Composeファイル (存在する場合) を選択するように求められます。 -
VS Codeウィンドウ (インスタンス) がリロードされ、開発コンテナーの構築が開始されます。進捗通知によってステータス更新が提供されます。
-
ビルドが完了すると、VS Codeは自動的にコンテナーに接続します。これで、コンテナー内からソースコードを操作できます。
詳細については、Dev Containersのドキュメントを参照してください。
既知の制限事項
このセクションには、WSLに関する一般的な既知の問題のリストが含まれています。これは問題の完全なリストを提供する意図ではなく、WSLでよく見られる一般的な問題の一部を強調することを目的としています。
WSLに関連するアクティブな問題のリストについては、こちらを参照してください。
WSL 1で開いているワークスペース内のフォルダーの名前を変更しようとすると、「EACCES: permission denied」エラーが表示されます。
これは、VS Codeによってアクティブなファイルウォッチャーが原因で発生する、WSLファイルシステムの実装における既知の問題です (Microsoft/WSL#3395、Microsoft/WSL#1956)。この問題はWSL 2でのみ修正されます。
この問題を回避するには、`remote.WSL.fileWatcher.polling`をtrueに設定します。ただし、ポーリングベースのファイル監視は、大規模なワークスペースではパフォーマンスに影響を与えます。
大規模なワークスペースの場合、ポーリング間隔を長くしたい場合は`remote.WSL.fileWatcher.pollingInterval`を増やし、監視するフォルダーを制御したい場合はfiles.watcherExcludeを使用します。
WSL 2にはそのファイルウォッチャーの問題はなく、新しい設定の影響も受けません。
WSL 1のGolang
問題 | 既存の問題 |
---|---|
DelveデバッガーがWSLで動作しない | go-delve/delve#810、Microsoft/vscode-go#926 |
WSL 1のNode.js
問題 | 既存の問題 |
---|---|
NodeJSエラー: spawn EACCES (このエラーの異なるバリアント) | Microsoft/WSL#3886 |
Webpack HMRが機能しない | Microsoft/WSL#2709 |
Node経由のFirebaseがWSLでのみ使用できないほど遅い | Microsoft/WSL#2657 |
Gitの制限事項
SSHを使用してGitリポジトリをクローンし、SSHキーにパスフレーズがある場合、VS Codeのプルおよび同期機能がリモートで実行されているときにハングする可能性があります。パスフレーズなしのSSHキーを使用するか、HTTPSを使用してクローンするか、コマンドラインから`git push`を実行して問題を回避してください。
Container Tools拡張機能の制限事項
Container Tools拡張機能はリモートでもローカルでも実行できますが、すでにローカルにインストールされている場合、まずローカルでアンインストールしない限り、リモートSSHホストにはインストールできません。この問題は、将来のVS Codeリリースで対処する予定です。
拡張機能の制限事項
多くの拡張機能はWSLで変更なしで動作します。ただし、場合によっては、特定の機能に変更が必要な場合があります。拡張機能の問題に遭遇した場合は、一般的な問題と解決策の概要をここで確認し、問題を報告する際に拡張機能の作成者に伝えることができます。
さらに、Alpine Linuxベースのディストリビューションを使用している場合にWSLにインストールされた一部の拡張機能は、拡張機能内のネイティブコードにおける`glibc`の依存関係が原因で機能しない場合があります。詳細については、Linuxでのリモート開発の記事を参照してください。
よくある質問
なぜ既定のディストリビューションの変更を求められるのですか?
**WSL: ディストリビューションを使用してWSLに接続**を使用し、Windows 10 バージョン1903 (2019年5月更新) 以前のWSLで実行している場合、WSLコマンドはまだ`-d`オプションをサポートしていないため、既定のディストリビューションでのみ機能するため、**既定のディストリビューション**を切り替えるように求められます。
wslconfig.exeを使用して、いつでも手動で既定のディストリビューションを切り替えることができます。
例
wslconfig /setdefault Ubuntu
インストールされているディストリビューションは、以下を使用して確認できます。
wslconfig /l
不足しているライブラリまたは依存関係に関するエラーが表示されます
一部の拡張機能は、特定のWSL Linuxディストリビューションの標準インストールでは見つからないライブラリに依存しています。パッケージマネージャーを使用して、Linuxディストリビューションに追加のライブラリを追加できます。UbuntuおよびDebianベースのディストリビューションの場合は、必要なライブラリをインストールするために`sudo apt-get install
WSL拡張機能の接続要件は何ですか?
WSL拡張機能とVS Code Serverは、以下の宛先への送信HTTPS (ポート443) 接続が必要です。
update.code.visualstudio.com
vscode.download.prss.microsoft.com
marketplace.visualstudio.com
*.gallerycdn.vsassets.io
(Azure CDN)
一部の拡張機能 (C#など) は、`download.microsoft.com`または`download.visualstudio.microsoft.com`から二次的な依存関係をダウンロードします。その他の拡張機能 (例: Visual Studio Live Share) は、追加の接続要件を持つ場合があります。問題が発生した場合は、拡張機能のドキュメントで詳細を確認してください。
サーバーとVS Codeクライアント間のその他すべての通信は、ランダムなローカルTCPポートを介して行われます。VS Code自体がアクセスする必要がある場所のリストは、ネットワーク接続に関する記事で確認できます。
プロキシの背後にいて接続の問題があります
プロキシ設定がWindows側またはWSL側のどちらかで不足している可能性があります。
リモートウィンドウがVS Code以外で開かれると、WSL拡張機能はWindows側でVS Codeサーバーをダウンロードしようとします。そのため、Windows側のプロキシ構成を使用します。
- OS設定から継承されます。
- Visual Studio Codeのネットワーク接続で説明されているとおり
リモートVS CodeがWSLターミナルから起動されると、ダウンロードはWSLディストリビューション内の`wget`を使用して行われます。プロキシ設定は以下で構成できます。
- wgetプロキシ設定: https://stackoverflow.com/questions/11211705/how-to-set-proxy-for-wget
- サーバーセットアップスクリプトで手動で
サーバーが起動して実行されると、*リモート*タブのプロキシ設定が使用されます。
拡張機能をローカル/リモートで強制的に実行できますか?
拡張機能は通常、ローカルまたはリモートのどちらかで実行されるように設計およびテストされており、両方ではありません。ただし、拡張機能がそれをサポートしている場合、settings.json
ファイルで特定の場所で強制的に実行できます。
例えば、以下の設定により、Container Tools拡張機能はローカルで実行され、Remote - SSH: 設定ファイルの編集拡張機能は既定の場所ではなくリモートで実行されます。
"remote.extensionKind": {
"ms-azuretools.vscode-containers": [ "ui" ],
"ms-vscode-remote.remote-ssh-edit": [ "workspace" ]
}
"workspace"
の代わりに"ui"
の値を指定すると、拡張機能はローカルのUI/クライアント側で実行されるよう強制されます。通常、これは**拡張機能を壊す可能性がある**ため、拡張機能のドキュメントで特に指示がない限り、テストにのみ使用する必要があります。詳細については、リモート開発のサポートに関する記事を参照してください。
拡張機能の作成者として、何をすべきですか?
VS Code拡張機能APIはローカル/リモートの詳細を抽象化するため、ほとんどの拡張機能は変更なしで動作します。ただし、拡張機能は任意のNodeモジュールやランタイムを使用できるため、調整が必要になる状況もあります。更新が不要であることを確認するために、拡張機能をテストすることをお勧めします。詳細については、リモート開発のサポートを参照してください。
質問またはフィードバック
- ヒントとテクニックまたはFAQを参照してください。
- Stack Overflowで検索します。
- 機能リクエストを追加するか、問題を報告してください。
- 弊社のドキュメントまたはVS Code自体に貢献します。
- 詳細については、CONTRIBUTINGガイドを参照してください。