Visual Studio 2022でvstest.console.exeをx86（32ビット）で実行する完全ガイド｜.runsettings・/Platform・–archの正しい使い方

「32-bit のネイティブ DLL に依存しているため、Visual Studio 2022 でもテストホストを x86（32 ビット）で起動したい」。そんな現場の悩みに、最短で確実に効く解をまとめました。ポイントは “vstest.console.exe 本体が 64 ビットでも問題ない”。/Platform や .runsettings、.NET CLI の --arch を正しく使えば、testhost を x86 で起動できます。以下で、目的別の手順、仕組み、つまずきやすい落とし穴、CI や IDE の具体設定まで網羅します。

結論（最短の実践手順）

目的	実行コマンド / 設定	要点
コマンドラインで testhost を x86 に固定	`vstest.console.exe MyTests.dll /Platform:x86`	`--x86` ではなく `/Platform:x86` を使用。 vstest.console.exe は親プロセスとして動き、子プロセスの testhost を x86 で起動します。
設定ファイルで恒久化（IDE/CLI 共通）	`<RunSettings> <RunConfiguration> <TargetPlatform>x86</TargetPlatform> </RunConfiguration> </RunSettings>`	ソリューション直下に `.runsettings` を置き、IDE の「Run Settings」から選択、または「Auto Detect runsettings」を有効化。
.NET CLI で x86 実行	ビルド済 DLL を走らせる: `dotnet vstest MyTests.dll --Platform x86` プロジェクトをビルドして走らせる: `dotnet test --arch x86`	`dotnet test` は `--arch` が効きます。`.runsettings` の `<TargetPlatform>` は `dotnet test` ではアーキ切替に効きません。
IDE（VS 2022）の Test メニューで切替	「Test > Processor Architecture for AnyCPU Projects > x86」	AnyCPU のテスト DLL に対して、IDE 側で実行時アーキを一括指定できます。
ホストの誤検出を明示的に回避	`<RunSettings> <RunConfiguration> <TargetPlatform>x86</TargetPlatform> <DotnetHostPath>C:\Program Files (x86)\dotnet\dotnet.exe</DotnetHostPath> </RunConfiguration> </RunSettings>`	.NET のホスト（dotnet.exe）が x64 を掴んでしまう環境で有効。`DotnetHostPath` で x86 の dotnet を明示。

なぜ「vstest.console.exe 自体の 32 ビット版」が不要なのか

Visual Studio 2022 では IDE 自体が 64 ビット化され、同梱の vstest.console.exe も 64 ビット配置（Program Files 側）になりました。ここで重要なのは「vstest.console.exe はあくまで“親”」という点です。実際にテストを実行するのは子プロセスの testhost.exe（.NET Framework）または testhost.dll（.NET / .NET Core）であり、/Platform や .runsettings の指定に基づいて、この testhost が x86 で起動します。つまり、親の vstest.console が 64 ビットでも、子の testhost を 32 ビットで起動できるため、多くのケースで “vstest.console の 32 ビット版そのもの” を探す必要はありません。

実行モード別の正しいスイッチと注意点

vstest.console.exe（VS が同梱するテストランナー）

コマンドは /Platform:x86 を使用します（--x86 は無効）。
/Settings:xxx.runsettings で <TargetPlatform>x86</TargetPlatform> を適用できます。
実行中はタスクマネージャーで testhost.exe *32 が起動しているか確認すると確実です。

vstest.console.exe .\tests\MyTests.dll /Settings:.runsettings /Platform:x86 /logger:trx

dotnet vstest（.NET CLI から VSTest を叩く）

ビルド済みの DLL を直接テストしたいときに有効です。
--Platform x86 を使用します。

dotnet vstest .\artifacts\bin\MyTests\net8.0\MyTests.dll --Platform x86

dotnet test（プロジェクトをビルドしてテスト）

--arch x86 でテストホスト実行のアーキテクチャを指定します。
.runsettings の <TargetPlatform> は dotnet test のアーキ切替には影響しません（--arch または x86 の dotnet を使う必要があります）。
--arch と -r|--runtime は併用しないのが安全策です。

dotnet test .\tests\MyTests\MyTests.csproj --arch x86 -c Release -l "trx;LogFileName=test.trx" -s .runsettings

dotnet x86 を明示したい場合

環境に x64 と x86 両方の .NET が入っていると、パスの解決順によって x64 の dotnet が使われることがあります。確実に x86 を使いたいなら、次のいずれかで固定します。

set PATH=C:\Program Files (x86)\dotnet;%PATH% のように PATH を先頭に通す。
前述の DotnetHostPath を .runsettings に設定。

.runsettings のベストプラクティス

最小構成（x86 固定）

<RunSettings>
  <RunConfiguration>
    <TargetPlatform>x86</TargetPlatform>
  </RunConfiguration>
</RunSettings>

ホストの誤検出対策（.NET x86 を固定）

<RunSettings>
  <RunConfiguration>
    <TargetPlatform>x86</TargetPlatform>
    <DotnetHostPath>C:\Program Files (x86)\dotnet\dotnet.exe</DotnetHostPath>
  </RunConfiguration>
</RunSettings>

プロジェクト／ソリューションへの適用

ソリューション直下の .runsettings を「Auto Detect runsettings」で自動検出。
IDE の「Test > Configure Run Settings」で手動選択も可。
Directory.Build.props やプロジェクトの PropertyGroup に RunSettingsFilePath を入れると、メンバー全員に行き渡らせやすくなります。

<Project>
  <PropertyGroup>
    <RunSettingsFilePath>$(SolutionDir).runsettings</RunSettingsFilePath>
  </PropertyGroup>
</Project>

IDE（Visual Studio 2022）での設定ポイント

AnyCPU テストの実行アーキは「Test > Processor Architecture for AnyCPU Projects」で切替可能（x86 / x64）。
テストの挙動は使用ランナー（VSTest か MSTest ランナー）でも変わります。VSTest モードでは /Platform と TargetPlatform が効きます。
ソリューション単位で .runsettings を選択すれば、メニューからの変更よりブレにくくなります。

ネイティブ DLL 連携の実務ノウハウ

配置ディレクトリの落とし穴

x86 に切替えても、依存 DLL（例：mylib.dll）が bin\x64 側に置かれていると DllNotFoundException を引き起こします。CopyToOutputDirectory とターゲット毎の出力ディレクトリを整理しましょう。

<ItemGroup>
  <None Include="native\x86\mylib.dll">
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    <Link>mylib.dll</Link>
  </None>
</ItemGroup>

NuGet のランタイム別配置（推奨）

自作ライブラリなら、runtimes/win-x86/native/mylib.dll の形でパッケージングすると、テスト／本番いずれも配置が安定します。

テストコードからビット数を自己診断

[Fact]
public void ホストは32ビットで起動しているはず()
{
    Assert.True(Environment.Is64BitProcess == false);
    Assert.Equal(4, IntPtr.Size); // 32bit は 4
}

CI/CD（エージェント）で x86 テストを安定させる

汎用スクリプト例（Windows, PowerShell）

# x86 の dotnet を優先
$env:PATH = "C:\Program Files (x86)\dotnet;" + $env:PATH

# ログ出力フォルダ

$results = "$pwd\TestResults"
mkdir $results -ea 0 | Out-Null

# .runsettings で情報収集＋ --arch x86 で実行

dotnet test .\tests\MyTests\MyTests.csproj `  --arch x86 -c Release`
-s .runsettings `  --results-directory $results`
-l "trx;LogFileName=tests.trx"

vstest.console を使うパイプライン

vstest.console.exe .\artifacts\bin\MyTests\net8.0\MyTests.dll ^
  /Platform:x86 ^
  /Settings:.runsettings ^
  /Logger:trx

ホストの解決に失敗する場合は、環境変数の DOTNET_ROOT(x86) / DOTNET_ROOT を使い分ける、あるいは .runsettings の DotnetHostPath で明示固定すると安定します。

トラブルシューティング（よくある 10 のつまずき）

「x86 にしたはずなのに 64 ビットで起動する」
- vstest.console の場合：/Platform:x86 を付け忘れていないか確認。
- dotnet test の場合：--arch x86 が必須。TargetPlatform は効きません。
- DotnetHostPath で x86 の dotnet.exe を明示するのも効果的。
.runsettings が適用されていない
ファイル名の拡張子が .runsettings になっているか、ソリューション直下か、IDE で選択されているかを再確認。
AnyCPU テストでの混乱
AnyCPU のままでも、IDE の「Processor Architecture for AnyCPU Projects」で x86 指定が可能。チームで共有したい場合は .runsettings の併用が安全。
ネイティブ DLL の見つからないエラー
出力先の bin\x86 に配置されているか、または runtimes/win-x86/native 経由で取り込めているかを点検。
パスが x64 の dotnet を指してしまう
CI では PATH の先頭に C:\Program Files (x86)\dotnet を通すか、DotnetHostPath を設定。
テストアダプタの不一致
Microsoft.NET.Test.Sdk と各フレームワーク（xUnit/NUnit/MSTest）のバージョン整合を確認。古いアダプタはアーキ検出に不具合を起こすことあり。
ARM 環境での挙動
Windows on Arm 環境では WoW64/エミュレーションにより x86/x64 の動作が混在します。安定させるには --arch または /Platform と DotnetHostPath を併用。
コードカバレッジやデータコレクタで落ちる
x86 化により収集器の依存が変わる場合があります。まずはコレクタを無効化して再実行し、段階的に戻すのが安全。
テストが検出されない
実行対象の DLL がターゲットフレームワークと合っているか（例：net8.0）、アダプタが正しく参照されているか確認。
「それでも 32 ビット版 vstest.console が欲しい」
実務上は不要です。どうしても単体の 32 ビットランチャーが必要な場合は、x86 の dotnet.exe と dotnet vstest を使う方がトラブルが少なく、保守も容易です。

仕組みの理解：テストホストとアーキテクチャ選択

VSTest モード（vstest.console / dotnet vstest / VS Test Explorer）：
親のランナーは 64 ビットでも、/Platform と <TargetPlatform> に従い testhost を x86 で起動。
.NET CLI（dotnet test）：
既定では「パスにある dotnet のビット数」を使うため、--arch x86 か x86 の dotnet を使う必要があります。TargetPlatform はこの振る舞いを上書きしません。
DotnetHostPath：
.runsettings の RunConfiguration に指定できる “テストホスト起動に使う dotnet のパス”。解決順の揺らぎを排除し、再現性を高めます。

チェックリスト（1 分で確認）

テスト実行時にタスクマネージャーで testhost.exe *32 が見えるか。
Environment.Is64BitProcess == false を検証するテストが通るか。
vstest.console なら /Platform:x86、dotnet test なら --arch x86 を付けているか。
.runsettings はソリューション直下 & Auto Detect が ON か（または手動選択済み）。
ネイティブ DLL は bin\x86 か runtimes/win-x86/native に配置されているか。
必要に応じて DotnetHostPath に C:\Program Files (x86)\dotnet\dotnet.exe を設定しているか。

ケーススタディ：SQLite の x86 ネイティブ DLL に依存するテスト

以下は「SQLite の x86 ネイティブ DLL に依存する」想定の最小構成です。ポイントは 3 つだけです。

/Platform:x86（または --arch x86）
<TargetPlatform>x86</TargetPlatform>
依存 DLL を bin\x86 へ確実に配置

.runsettings

<RunSettings>
  <RunConfiguration>
    <TargetPlatform>x86</TargetPlatform>
    <ResultsDirectory>.\TestResults</ResultsDirectory>
  </RunConfiguration>
</RunSettings>

csproj（抜粋）

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <PlatformTarget>x86</PlatformTarget>
    <IsPackable>false</IsPackable>
  </PropertyGroup>



PreserveNewest
sqlite3.dll

実行

# VS 同梱ランナーで
vstest.console.exe .\bin\x86\Debug\net8.0\MyTests.dll /Platform:x86 /Settings:.runsettings

# .NET CLI で

dotnet test --arch x86 -s .runsettings

FAQ

Q. VS 2019 に戻さないと x86 テストは無理？
A. 不要です。VS 2022 でも /Platform:x86 や --arch x86、DotnetHostPath で確実に x86 実行できます。

Q. プロジェクトを x86 でビルドしているのに 64 ビットで起動します
A. ビルド構成（PlatformTarget）と実行アーキは別です。vstest.console は /Platform、dotnet test は --arch で“実行時”を指定してください。

Q. .runsettings の TargetPlatform だけで十分？
A. vstest.console/VS では有効ですが、dotnet test の実行アーキ切替には効きません。CLI の場合は --arch x86 を使いましょう。

Q. 「vstest.console.exe の 32 ビット版」をどこかから入手できますか？
A. 実務上のメリットは乏しく、推奨しません。vstest.console が 64 ビットでも、子の testhost を x86 で起動できます。どうしても単体 EXE の運用が必要なら、x86 の dotnet と dotnet vstest を活用するのが現実的です。

Q. MSTest / xUnit / NUnit で違いはありますか？
A. いずれも VSTest 経由で動く限りは上記のルールに従います。アダプタや SDK のバージョン差で挙動が変わる場合があるので、テスト基盤のバージョンはなるべく揃えてください。

まとめ

VS 2022 環境でも x86 テストは完全に可能。/Platform:x86、<TargetPlatform>x86</TargetPlatform>、--arch x86 を正しく使い分ける。
CLI でのアーキ切替は dotnet test --arch x86 が確実。TargetPlatform は dotnet test には効かない点に注意。
ホスト誤検出は DotnetHostPath で x86 の dotnet.exe を明示して回避。
ネイティブ DLL の配置とアダプタの整合性を見直すと、x86 化によるエラーの大半は解決します。

これらを押さえておけば、「32 ビット依存のライブラリを VS 2022 でテストできない」という悩みはきれいに解消できます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Visual Studio 2022でvstest.console.exeをx86（32ビット）で実行する完全ガイド｜.runsettings・/Platform・–archの正しい使い方

結論（最短の実践手順）

なぜ「vstest.console.exe 自体の 32 ビット版」が不要なのか

実行モード別の正しいスイッチと注意点

vstest.console.exe（VS が同梱するテストランナー）

dotnet vstest（.NET CLI から VSTest を叩く）

dotnet test（プロジェクトをビルドしてテスト）

dotnet x86 を明示したい場合

.runsettings のベストプラクティス

最小構成（x86 固定）

ホストの誤検出対策（.NET x86 を固定）

プロジェクト／ソリューションへの適用

IDE（Visual Studio 2022）での設定ポイント

ネイティブ DLL 連携の実務ノウハウ

配置ディレクトリの落とし穴

NuGet のランタイム別配置（推奨）

テストコードからビット数を自己診断

CI/CD（エージェント）で x86 テストを安定させる

汎用スクリプト例（Windows, PowerShell）

vstest.console を使うパイプライン

トラブルシューティング（よくある 10 のつまずき）

仕組みの理解：テストホストとアーキテクチャ選択

チェックリスト（1 分で確認）

ケーススタディ：SQLite の x86 ネイティブ DLL に依存するテスト

FAQ

まとめ

この記事を書いた人

コメント

コメントするコメントをキャンセル

Visual Studio 2022でvstest.console.exeをx86（32ビット）で実行する完全ガイド｜.runsettings・/Platform・–archの正しい使い方

結論（最短の実践手順）

なぜ「vstest.console.exe 自体の 32 ビット版」が不要なのか

実行モード別の正しいスイッチと注意点

vstest.console.exe（VS が同梱するテストランナー）

dotnet vstest（.NET CLI から VSTest を叩く）

dotnet test（プロジェクトをビルドしてテスト）

dotnet x86 を明示したい場合

.runsettings のベストプラクティス

最小構成（x86 固定）

ホストの誤検出対策（.NET x86 を固定）

プロジェクト／ソリューションへの適用

IDE（Visual Studio 2022）での設定ポイント

ネイティブ DLL 連携の実務ノウハウ

配置ディレクトリの落とし穴

NuGet のランタイム別配置（推奨）

テストコードからビット数を自己診断

CI/CD（エージェント）で x86 テストを安定させる

汎用スクリプト例（Windows, PowerShell）

vstest.console を使うパイプライン

トラブルシューティング（よくある 10 のつまずき）

仕組みの理解：テストホストとアーキテクチャ選択

チェックリスト（1 分で確認）

ケーススタディ：SQLite の x86 ネイティブ DLL に依存するテスト

FAQ

まとめ

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル