🚀 VS Code で で入手しましょう!

WSL での開発

Visual Studio Code WSL 拡張機能を使用すると、Windows Subsystem for Linux (WSL) を VS Code から直接フルタイムの開発環境として使用できます。Linux ベースの環境で開発し、Linux 固有のツールチェーンとユーティリティを使用し、Linux ベースのアプリケーションをすべて快適な Windows 環境から実行およびデバッグできます。

この拡張機能は、WSL 内でコマンドやその他の拡張機能を直接実行するため、パスの問題、バイナリ互換性、またはその他のクロス OS の課題を気にすることなく、WSL またはマウントされた Windows ファイルシステム (例: /mnt/c) にあるファイルを編集できます。この拡張機能は、VS Code Server を WSL 内にインストールします。サーバーは、WSL に既存の VS Code インストールとは独立しています。

WSL Architecture

これにより、VS Code は、コードがホストされている場所に関係なく、完全な IntelliSense (補完)、コードナビゲーション、デバッグなど、ローカル品質の開発体験を提供できます。

はじめに

注: このトピックを確認した後、入門編の WSL チュートリアル を開始できます。

インストール

開始するには、以下が必要です。

  1. お好みの Linux ディストリビューションとともに Windows Subsystem for Linux をインストールします。

    注: WSL 1 には、特定のタイプの開発に関する 既知の制限事項 がいくつかあります。また、Alpine Linux にインストールされた拡張機能は、拡張機能内のネイティブソースコードに glibc 依存関係があるため、動作しない場合があります。詳細については、リモート開発と Linux の記事を参照してください。

  2. Windows 側 (WSL 内ではない) に Visual Studio Code をインストールします。

    注: インストール中に 追加タスクの選択 を求められたら、code コマンドを使用して WSL でフォルダーを簡単に開けるように、必ず PATH に追加 オプションをオンにしてください。

  3. WSL 拡張機能 をインストールします。VS Code で他のリモート拡張機能を使用する予定がある場合は、Remote Development 拡張機能パック をインストールすることもできます。

リモートフォルダーまたはワークスペースを開く

WSL ターミナルから

Visual Studio Code で Linux 用 Windows サブシステム内のフォルダーを開くことは、コマンドプロンプトまたは PowerShell から Windows フォルダーを開くのと非常によく似ています。

  1. WSL ターミナルウィンドウ を開きます (スタートメニュー項目を使用するか、コマンドプロンプト / PowerShell から wsl と入力します)。

  2. VS Code で開きたいフォルダーに移動します (Windows ファイルシステムのマウント (/mnt/c など) を含むが、これらに限定されません)

  3. ターミナルで code . と入力します。これを初めて行う場合は、WSL で実行するために必要なコンポーネントを VS Code がフェッチするのを確認できます。これは短時間で完了し、一度だけ必要です。

    注: このコマンドが機能しない場合は、ターミナルを再起動するか、VS Code をインストールしたときにパスに追加していない可能性があります。

  4. しばらくすると、新しい VS Code ウィンドウが表示され、VS Code が WSL でフォルダーを開いているという通知が表示されます。

    WSL Starting notification

    VS Code は WSL での構成を続行し、進捗状況を最新の状態に保ちます。

  5. 完了すると、左下隅に WSL インジケーターが表示され、通常どおり VS Code を使用できるようになります!

    WSL Status Bar Item

以上です! このウィンドウで実行する VS Code 操作はすべて WSL 環境で実行されます。編集やファイル操作から、デバッグ、ターミナルの使用など、すべてです。

VS Code から

または、VS Code から直接 WSL ウィンドウを開くことができます。

  1. VS Code を起動します。
  2. F1 キーを押して、デフォルトのディストリビューションの場合は WSL: WSL に接続 を選択し、特定のディストリビューションの場合は WSL: ディストリビューションを使用して WSL に接続 を選択します。
  3. ファイルメニューを使用してフォルダーを開きます。

既にフォルダーを開いている場合は、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 で同じリポジトリを使用している場合は、必ず一貫した行末記号を設定してください。詳細については、ヒントとテクニック を参照してください。

また、Windows Git 資格情報マネージャーを使用するように WSL を構成することで、パスワードを回避することもできます。詳細については、ヒントとテクニック を参照してください。

拡張機能の管理

VS Code は、拡張機能を UI / クライアント側のローカルまたは WSL のいずれかの場所で実行します。テーマやスニペットなど、VS Code UI に影響を与える拡張機能はローカルにインストールされますが、ほとんどの拡張機能は WSL 内に常駐します。

拡張機能ビューから拡張機能をインストールすると、正しい場所に自動的にインストールされます。インストールが完了すると、カテゴリグループに基づいて拡張機能がインストールされている場所を確認できます。ローカル - インストール済み カテゴリと WSL 用のカテゴリがあります。

Workspace Extension Category

Local Extension Category

注: 拡張機能の作成者で、拡張機能が正しく動作しない場合、または間違った場所にインストールされる場合は、詳細について リモート開発のサポート を参照してください。

実際にはリモートで実行する必要があるローカル拡張機能は、ローカル - インストール済み カテゴリで淡色表示され、無効になります。インストール を選択して、リモートホストに拡張機能をインストールします。

Disabled Extensions w/Install Button

拡張機能ビューに移動し、ローカル - インストール済み タイトルバーの右側にあるクラウドボタンを使用して ローカル拡張機能を WSL: {名前} にインストール を選択することで、ローカルにインストールされているすべての拡張機能を WSL 内にインストールすることもできます。これにより、ドロップダウンが表示され、WSL インスタンスにインストールするローカルにインストールされた拡張機能を選択できます。

Install all extensions

WSL でのターミナルの開き方

VS Code から WSL でターミナルを開くのは簡単です。フォルダーが WSL で開かれると、VS Code で開く ターミナルウィンドウ (ターミナル > 新しいターミナル) はすべて、ローカルではなく WSL で自動的に実行されます。

この同じターミナルウィンドウから code コマンドラインを使用して、WSL で新しいファイルまたはフォルダーを開くなど、さまざまな操作を実行することもできます。コマンドラインから使用できるオプションを確認するには、code --help と入力します。

Using the code CLI

WSL でのデバッグ

WSL でフォルダーを開いたら、アプリケーションをローカルで実行する場合と同じ方法で VS Code のデバッガーを使用できます。たとえば、launch.json で起動構成を選択してデバッグを開始すると (F5)、アプリケーションはリモートホストで起動し、デバッガーがアタッチされます。

VS Code のデバッグ機能を .vscode/launch.json で構成する方法の詳細については、デバッグ ドキュメントを参照してください。

WSL 固有の設定

VS Code のローカルユーザー設定は、WSL でフォルダーを開いたときにも再利用されます。これにより、ユーザーエクスペリエンスの一貫性が保たれますが、ローカルマシンと WSL でこれらの設定の一部を変更したい場合があります。幸いなことに、WSL に接続したら、コマンドパレット (F1) から 基本設定: リモート設定を開く コマンドを実行するか、設定エディターで リモート タブを選択して、WSL 固有の設定を行うこともできます。これらは、WSL でフォルダーを開くたびに、ローカル設定よりも優先されます。

高度: 環境セットアップスクリプト

VS Code Remote が WSL で起動されると、シェル起動スクリプトは実行されません。これは、シェル用に調整された起動スクリプトの問題を回避するために行われました。追加のコマンドを実行したり、環境を変更したりする場合は、セットアップスクリプト ~/.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 内に保存されているソースコードを操作できます! 次の手順に従ってください。

  1. まだ行っていない場合は、Docker Desktop の WSL 2 サポートをインストールしてセットアップ します。

    ヒント: 設定 > リソース > WSL 統合 に移動し、使用する WSL ディストリビューションとの Docker 統合を有効にします。

  2. まだ行っていない場合は、WSL 拡張機能とともに Dev Containers 拡張機能をインストールします。

  3. 次に、通常どおり WSL でソースコードフォルダーを開き ます。

  4. フォルダーが WSL で開いたら、コマンドパレット (F1) から Dev Containers: コンテナで再度開く を選択します。

  5. フォルダーに .devcontainer/devcontainer.json ファイルがない場合は、フィルター可能なリストまたは既存の Dockerfile または Docker Compose ファイル (存在する場合) から開始点を選択するように求められます。

    Select a node dev container definition

  6. VS Code ウィンドウ (インスタンス) がリロードされ、開発コンテナのビルドが開始されます。進行状況通知にステータスの更新が表示されます。

    Dev Container Progress Notification

  7. ビルドが完了すると、VS Code は自動的にコンテナに接続します。これで、コンテナ内からソースコードを操作できます。

詳細については、Dev Containers ドキュメント を参照してください。

既知の制限事項

このセクションでは、WSL に関する一般的な既知の問題のリストを示します。目的は、問題の完全なリストを提供することではなく、WSL で見られる一般的な問題をいくつか強調することです。

WSL に関連するアクティブな問題のリストについては、こちら を参照してください。

WSL 1 で開いているワークスペースでフォルダーの名前を変更しようとすると、EACCES: 許可が拒否されましたというエラーが表示されます

これは、WSL ファイルシステムの実装 (Microsoft/WSL#3395、Microsoft/WSL#1956) の既知の問題であり、VSCode によってアクティブなファイルウォッチャーが原因で発生します。この問題は 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
WSL でのみ Firebase が非常に遅い Microsoft/WSL#2657

Git の制限事項

SSH を使用して Git リポジトリをクローンし、SSH キーにパスフレーズがある場合、リモートで実行すると、VS Code の pull および sync 機能がハングする可能性があります。パスフレーズなしで SSH キーを使用するか、HTTPS を使用してクローンするか、コマンドラインから git push を実行して問題を回避してください。

Docker 拡張機能の制限事項

Docker 拡張機能はリモートとローカルの両方で実行できますが、ローカルに既にインストールされている場合は、最初にローカルでアンインストールしないと、リモート SSH ホストにインストールできません。この問題は今後の VS Code リリースで対処する予定です。

拡張機能の制限事項

多くの拡張機能は、変更なしで WSL で動作します。ただし、場合によっては、特定の機能で変更が必要になることがあります。拡張機能の問題が発生した場合は、こちら を参照して、問題の報告時に拡張機能の作成者に伝えることができる一般的な問題と解決策の概要を確認してください。

さらに、Alpine Linux ベースのディストリビューションを使用する場合、WSL にインストールされた一部の拡張機能は、拡張機能内のネイティブコードに glibc 依存関係があるため、動作しない場合があります。詳細については、Linux でのリモート開発 の記事を参照してください。

よくある質問

デフォルトのディストリビューションを変更するように求められるのはなぜですか?

WSL: ディストリビューションを使用して WSL に接続 を使用し、Windows 10 2019 年 5 月更新 (バージョン 1903) より前の WSL で実行している場合、WSL コマンドはまだ -d オプションをサポートしていないため、デフォルトのディストリビューション を切り替えるように求められます。

wslconfig.exe を使用して、デフォルトのディストリビューションを手動で切り替えることはいつでもできます。

例

wslconfig /setdefault Ubuntu

インストールされているディストリビューションを確認するには、次を使用します。

wslconfig /l

ライブラリまたは依存関係が見つからないというエラーが表示されます

一部の拡張機能は、特定の WSL Linux ディストリビューションのバニラインストールにはないライブラリに依存しています。パッケージマネージャーを使用して、追加のライブラリを Linux ディストリビューションに追加できます。Ubuntu および Debian ベースのディストリビューションの場合は、sudo apt-get install <package> を実行して必要なライブラリをインストールします。追加のインストール手順については、拡張機能または言及されているランタイムのドキュメントを確認してください。

WSL 拡張機能の接続要件は何ですか?

WSL 拡張機能と VS Code Server には、次の宛先へのアウトバウンド HTTPS (ポート 443) 接続が必要です。

  • update.code.visualstudio.com
  • marketplace.visualstudio.com
  • vscode.blob.core.windows.net
  • *.vo.msecnd.net (Azure CDN)
  • *.gallerycdn.vsassets.io (Azure CDN)

一部の拡張機能 (C# など) は、download.microsoft.com または download.visualstudio.microsoft.com からセカンダリ依存関係をダウンロードします。その他 (Visual Studio Live Share など) には、追加の接続要件がある場合があります。問題が発生した場合は、拡張機能のドキュメントを参照してください。

サーバーと VS Code クライアント間の他のすべての通信は、ランダムなローカル TCP ポートを介して行われます。VS Code 自体がアクセスする必要がある場所のリストは、ネットワーク接続に関する記事 にあります。

プロキシの背後にいて、接続に問題があります

プロキシ設定が Windows 側または WSL 側のいずれかで欠落している可能性があります。

VSCode からリモートウィンドウが開かれると、WSL 拡張機能は Windows 側で VSCode サーバーをダウンロードしようとします。したがって、Windows 側のプロキシ構成を使用します。

WSL ターミナルからリモート VSCode が起動されると、ダウンロードは WSL ディストリビューションで wget を使用して行われます。プロキシ設定は次で構成できます。

サーバーが起動して実行されると、リモート タブのプロキシ設定が使用されます。

拡張機能をローカル/リモートで強制的に実行できますか?

拡張機能は通常、ローカルまたはリモートのいずれかで実行するように設計およびテストされており、両方ではありません。ただし、拡張機能がサポートしている場合は、settings.json ファイルで特定の場所で実行するように強制できます。

たとえば、以下の設定では、Docker 拡張機能をローカルで実行し、Remote - SSH: 構成ファイルの編集 拡張機能をデフォルトではなくリモートで実行するように強制します。

"remote.extensionKind": {
    "ms-azuretools.vscode-docker": [ "ui" ],
    "ms-vscode-remote.remote-ssh-edit": [ "workspace" ]
}

"workspace" の代わりに "ui" の値を指定すると、拡張機能をローカル UI/クライアント側で強制的に実行できます。通常、拡張機能のドキュメントに特に記載がない限り、これはテストにのみ使用する必要があります。拡張機能が破損する可能性がある ためです。詳細については、リモート開発のサポート に関する記事を参照してください。

拡張機能の作成者として、何をする必要がありますか?

VS Code 拡張機能 API はローカル/リモートの詳細を抽象化するため、ほとんどの拡張機能は変更なしで動作します。ただし、拡張機能は任意の node モジュールまたはランタイムを使用できるため、調整が必要になる場合があります。更新が必要ないことを確認するために、拡張機能をテストすることをお勧めします。詳細については、リモート開発のサポート を参照してください。

質問またはフィードバック

04/03/2025