リモートテスト (試験的プレビュー)

[アーティクル]
11/30/2023

開発者は、リモートテストを使用して、Visual Studio 2022 をリモート環境に接続し、テストの実行やデバッグを行うことができます。この機能は、さまざまな Windows や Linux オペレーティングシステムなど、複数の異なるターゲット環境にコードを展開するクロスプラットフォームの開発者にとって便利です。たとえば、通常、開発者は変更を CI パイプラインにプッシュして、Linux で実行されているテストからフィードバックを取得します。リモートテスト機能を使用すると、テストエクスプローラーをリモート環境に接続することで、Visual Studio から直接 Linux テストを実行できます。

必要条件

リモートテストの実験段階のバージョンには、次の要件が適用されます:

Visual Studio 2022 Update 17.0 プレビュー 3 以降を実行している必要があります。
現在、この機能は .NET テストおよび .NET Framework テストのみをサポートしています。
- 他の言語でのリモートテストのサポートに関心をお持ちの場合は、提案を提出するか、既存の提案に賛成してください。 C++ リモートテストのサポート。
現在、この機能はリモート環境で Windows、Ubuntu、Debian イメージをサポートしています。 .NET Framework の場合、リモート Windows 環境のみがサポートされます。
現在、環境のプロビジョニングの大部分はユーザーの仕様に任されています。

ユーザーは、ターゲット環境に必要な依存関係をインストールする必要があります。たとえば、テストのターゲットが .NET 6.0 であれば、Dockerfile を介してコンテナーに .NET 6.0 がインストールされていることを確認する必要があります。リモート環境に .NET Core をインストールするように求められる場合があります。これは、リモートでテストを実行して検出するために必要です。
[出力]>[テスト]ペインを使用して、リモート環境への接続状態の監視を計画します。

たとえば、コンテナーが停止すると、[出力]>[テスト] ペインにメッセージが表示されます。この機能ではすべてのシナリオが検出されない可能性があるため、接続が失われたように見える場合は、出力を確認することを計画してください。特に、[出力] ペインが "テスト" に設定されていない場合は、メッセージがすぐに表示されないことがあります。接続が失われた場合は、テストエクスプローラーの [環境] ドロップダウンを使用して接続をローカル環境に戻し、リモート環境をもう一度選択して再接続できます。

リモートテスト環境を設定する

環境は、ソリューションのルートにある testenvironments.json ファイルを使用して指定します。 json ファイル構造は、次のスキーマを実装します:

{
    "version": "1", // value must be 1
    "environments": [
        { "name": "<unique name>", ... },
        ...
    ]
}

testenvironments.json の環境のプロパティ

testenvironments.json ファイルには、次の環境プロパティがあります。

プロパティ	タイプ	説明
`name`	string	テストエクスプローラーに表示されるユーザーフレンドリな環境名。これは testEnvironments.json ファイル内で一意にする必要があります。
`localRoot`	string	[省略可能] ローカルコンピューターのパス (絶対パスまたはソリューションディレクトリの相対パス)。リモート環境に投影されます。指定しない場合、既定値は Git リポジトリのコンテキスト内のリポジトリルートです (Visual Studio 2022 バージョン 17.1 以降)。 Git リポジトリの外部では、既定値はソリューションディレクトリです。
`type`	enum	リモート環境の種類を示します。この値には、`docker`、`wsl`、または `ssh` を指定できます。
`dockerImage`	string	Docker 環境に読み込む Docker イメージの名前。この値は、環境 `type` が `docker` の場合に必要です。
`dockerFile`	string	イメージをビルドし、Docker 環境で読み込むための Docker ファイルのパスであり、ソリューションディレクトリに相対。この値は、環境 `type` が `docker` の場合に必要です。
`wslDistribution`	string	ローカル WSL ディストリビューションの名前であり、そこでテスト環境を実行します。この値は、環境 `type` が `wsl` の場合に必要です。
`remoteUri`	string	リモートコンピューターへの接続を指定する uri。たとえば、`ssh://user@hostname:22` のようにします。この値は、環境 `type` が `ssh` の場合に必要です。

Note

どちらのプロパティも dockerImage または dockerFile を指定する必要がありますが、両方のプロパティを指定する必要はありません。

ローカルコンテナーの接続

ローカルで動作しているコンテナーに接続するには、ローカルマシンに Docker Desktop が必要です。必要に応じて、パフォーマンス向上のために WSL2 統合を有効にします。

Dockerfile の場合、ソリューションのルートにある testEnvironments.json ファイルで環境を指定できます。次のプロパティを使います。

{
    "name": "<name>",
    "type": "docker",
    "dockerImage": "<docker image tag>",
}

次の例は、<mcr.microsoft.com/dotnet/core/sdk> という名前のローカルコンテナーイメージの testenvironments.json ファイルを示しています。

{
    "version": "1",
    "environments": [
        {
            "name": "linux dotnet-core-sdk-3.1",
            "type": "docker",
            "dockerImage": "mcr.microsoft.com/dotnet/core/sdk"
        }
    ]
}

次の例は、.NET 5.0 をターゲットにしたテストを実行するための Dockerfile を示しています。 2 行目は、コンテナー内でデバッガーが接続して実行できることを確認しています。

FROM mcr.microsoft.com/dotnet/core/sdk:5.0

RUN wget https://aka.ms/getvsdbgsh && \
    sh getvsdbgsh -v latest  -l /vsdbg

コンテナーには、ローカルコンピューター上でビルトされたイメージが必要です。コマンド docker build -t <docker image name> -f <path to Dockerfile> . を使用してコンテナーをビルドできます。コマンドの最後にピリオド . を必ず含めます。

次の例は、dockerImage プロパティの代わりに dockerFile プロパティを使用する方法を示しています。

{
    "version": "1",
    "environments": [
        {
            "name": "GitServiceUnix",
            "type": "docker",
            "dockerFile": "Dockerfile.test"
        }
    ]
}

ローカルの WSL2 接続

リモートから WSL2 上でテストを実行するには、ローカルコンピューター上で WSL2 統合を有効にする必要があります。

次のスキーマを使用して、ソリューションのルートにある testEnvironments.json ファイルで環境を指定できます。 wslDistribution プロパティの <Ubuntu> 値を WSL2 ディストリビューションのインストールに置き換えます。

{
    "version": "1",
    "environments": [
        {
            "name": "WSL-Ubuntu",
            "type": "wsl",
            "wslDistribution": "Ubuntu"
        }
    ]
}

SSH 接続

[ツール] > [オプション] > [クロスプラットフォーム] > [接続マネージャー] で、SSH 接続の追加と削除を実行できます。 [追加] を選択して、ホスト名、ポート、必要な資格情報を入力します。

次のスキーマを使用して、ソリューションのルートにある testEnvironments.json ファイルで環境を指定できます。 remoteUri プロパティの <ssh://user@hostname:22> 値を SSH 値に置き換えます。

{
    "version": "1",
    "environments": [
        {
            "name": "ssh-remote",
            "type": "ssh",
            "remoteUri": "ssh://user@hostname:22"
        }
    ]
}

リモート Windows 環境の前提条件

リモート Windows 環境の次の前提条件を確認します。

リモートマシンで Windows Projected File System が有効になっていることを確認します。管理者の PowerShell ウィンドウから次のコードを実行して有効にすることができます:
```
 Enable-WindowsOptionalFeature -Online -FeatureName Client-ProjFS -NoRestart
```
必要に応じて、環境を再起動します。
SSH が設定されていることを確認します。手順については、OpenSSH のインストールに関する記事を参照してください。管理者 PowerShell ウィンドウから次のコマンドを実行して、SSH サーバーを起動します。
```
Start-Service sshd
```
テストに必要な適切な .NET ランタイムがインストールされていることを確認します。 Windows 用 .NET をダウンロードできます。
テストをデバッグするための環境を準備します:
1. リモート環境にリモートツール SKU をインストールします。
2. 管理者としてリモートデバッガーを起動し、接続するためのアクセス許可が Visual Studio ユーザーにあることを確認します。

リモート Linux 環境の前提条件

リモート Linux 環境の次の前提条件を確認します。

ssh が構成され、実行されていることを確認します。
パッケージマネージャーを使用して fuse3 をインストールします。
テストに必要な適切な .NET ランタイムがリモート Linux 環境にインストールされていることを確認します。

テストエクスプローラーを使用したリモートテストの実行とデバッグ

テストエクスプローラーを使用してリモート環境テストを実行およびデバッグする方法を次に示します。

アクティブな環境は、テストエクスプローラーツールバーのドロップダウンを使用して選択します。現在、アクティブにできるテスト環境は一度に 1 つだけです。
環境を選択すると、テストが検出され、新しい環境で実行されます。
これで、リモート内でテストを実行し、環境内でテストをデバッグできるようになりました。
テストエクスプローラーでは、不足している環境の前提条件をインストールし、不足している依存関係のインストールを試みることができます。ただし、リモート環境のプロビジョニングの大部分は、ユーザーの仕様に従います。

リモート テスト (試験的プレビュー)

必要条件

リモート テスト環境を設定する

testenvironments.json の環境のプロパティ

ローカル コンテナーの接続

ローカルの WSL2 接続

SSH 接続

リモート Windows 環境の前提条件

リモート Linux 環境の前提条件

テスト エクスプローラーを使用したリモート テストの実行とデバッグ

関連するコンテンツ

フィードバック

フィードバック

その他のリソース

リモートテスト (試験的プレビュー)

リモートテスト環境を設定する

ローカルコンテナーの接続

テストエクスプローラーを使用したリモートテストの実行とデバッグ