.NET 11でVSTest/Microsoft.NET.Test.SdkからNewtonsoft.Json依存が削除される変更は、テストコードやテスト拡張がNewtonsoft.Jsonを「暗黙的に使っていた」場合にだけ対応が必要です。結論として、JsonConvert、JObject、JTokenなどを使っているテストプロジェクトは、Newtonsoft.Jsonを明示的にPackageReferenceへ追加してください。通常のアプリ本体や、すでにNewtonsoft.Jsonを直接参照しているテストプロジェクトは、多くの場合そのまま動きます。
この変更は、2026年5月5日に.NET DocsのBreaking changeドキュメントとしてマージされた内容で、.NET 11 Preview 4からVSTestとMicrosoft.NET.Test.SdkがNewtonsoft.Jsonへの推移的依存を持たなくなる、というものです。VSTest内部では.NET向けにSystem.Text.Json、.NET Framework向けにJSONiteが使われます。(GitHub)
.NET 11でVSTestのNewtonsoft.Json依存削除は何が変わるのか
今回の.NET documentation updateで重要なのは、「Newtonsoft.Jsonが使えなくなる」ではなく、「VSTestがたまたま持ち込んでいたNewtonsoft.Jsonに頼れなくなる」という点です。
以前は、Microsoft.NET.Test.Sdkを参照しているテストプロジェクトで、Newtonsoft.Jsonを直接追加していなくても、推移的依存としてNewtonsoft.Jsonの型をコンパイル時や実行時に利用できるケースがありました。.NET 11以降はこの前提が崩れます。公式ドキュメントでは、この変更はsource compatibilityとbinary compatibilityに影響し得る破壊的変更として整理されています。(GitHub)
| 観点 | 変更前 | .NET 11 Preview 4以降 |
|---|---|---|
| VSTestのJSON処理 | Newtonsoft.Jsonに依存 | .NETではSystem.Text.Json、.NET FrameworkではJSONiteを使用 |
Microsoft.NET.Test.Sdk経由の依存 | Newtonsoft.Jsonが推移的に入る場合があった | Newtonsoft.Jsonは推移的依存ではなくなる |
| テストコードでの利用 | 直接参照なしでも動くことがあった | 直接PackageReferenceが必要 |
| 影響の種類 | 暗黙依存により問題が隠れやすい | ビルドエラー、実行時エラー、拡張ロード失敗として表面化 |
| 主な対応 | 不要な場合が多かった | 使っているプロジェクトに明示的なパッケージ参照を追加 |
Microsoftの.NET Blogでも、VSTestはdotnet testやVisual StudioのTest Explorerを支えるテストプラットフォームであり、今回の変更は.NET 11 Preview 4とVisual Studio 18.8から導入される予定だと説明されています。記事内では、.NET 11 Preview 4は2026年5月12日、Visual Studio 18.8 Insiders 1は2026年6月9日が目安として示されています。(Microsoft for Developers)
影響を受けるプロジェクトと受けないプロジェクト
まず確認すべきなのは、「自分のテストプロジェクトがNewtonsoft.Jsonを使っているか」「使っている場合、それを自分で参照しているか」です。
| プロジェクトの状態 | 影響 | 対応 |
|---|---|---|
Newtonsoft.Jsonを使っていない | ほぼなし | 追加対応は不要 |
Newtonsoft.Jsonを直接PackageReferenceしている | 基本的に小さい | 通常はそのまま。バージョン管理だけ確認 |
テストコードでJsonConvert、JObject、JTokenを使うが直接参照がない | 影響あり | テストプロジェクトにNewtonsoft.Jsonを追加 |
ExcludeAssets=runtimeで実行時アセットを除外している | 影響あり | runtime除外を外す、または実行時にDLLが入るよう修正 |
| テストアダプターやデータコレクターが暗黙依存している | 影響あり | 拡張側に直接依存を追加。利用者側は更新版を待つか一時回避 |
VSTestの通信APIでJTokenベースの型を直接使っている | 影響あり | API変更に合わせてコード修正 |
Microsoftの説明では、多くのテストプロジェクトは影響を受けません。影響が出るのは、VSTestが持ち込んでいたNewtonsoft.Jsonを自分の依存関係のように使っていたケースです。(Microsoft for Developers)
よくあるエラーと原因
この変更による問題は、静かにテスト結果だけが変わるというより、ビルドエラーやテスト実行時エラーとして分かりやすく出る可能性が高いです。Microsoftのブログでも、失敗はテスト実行結果、TRX、Azure DevOpsやGitHubのテスト表示に流れると説明されています。(Microsoft for Developers)
| 症状 | 典型的な原因 | 確認ポイント | 対応 |
|---|---|---|---|
Newtonsoft.Json名前空間が見つからない | テストコードが暗黙依存していた | .csprojにNewtonsoft.Jsonの直接参照がない | PackageReferenceを追加 |
JsonConvert、JObject、JTokenが解決できない | コンパイル時の参照が消えた | using Newtonsoft.Json;やNewtonsoft.Json.Linqを使っている | テストプロジェクトに直接参照 |
FileNotFoundExceptionでNewtonsoft.Jsonが読み込めない | 実行時アセットを除外していた | ExcludeAssetsにruntimeが含まれる | runtime除外を外す |
| データコレクターやテストアダプターのロード失敗 | 拡張がVSTest側のDLLに依存していた | エラーメッセージに拡張名が出る | 拡張を更新、または拡張側に依存を追加 |
| VSTest通信APIまわりのコンパイルエラー | JTokenベースの公開API削除 | CommunicationUtilitiesを直接使っている | API変更に合わせて修正 |
特に注意したいのは、アプリ本体ではなくテストプロジェクト側でNewtonsoft.Jsonを使っているケースです。アプリ本体にNewtonsoft.Jsonが入っていても、テストプロジェクト自身がJsonConvertやJObjectを直接使うなら、テストプロジェクト側にも依存関係を明示した方が安全です。
まず確認すべき設定とコード
Newtonsoft.Jsonを使っている箇所を検索する
リポジトリ内でNewtonsoft.Jsonの利用箇所を洗い出します。ripgrepが使える環境なら、次のように確認できます。
rg "Newtonsoft\.Json|JsonConvert|JObject|JArray|JToken|ExcludeAssets>runtime" .Windows PowerShellで標準的に確認するなら、次のように検索できます。
Get-ChildItem -Recurse -Include *.cs,*.fs,*.vb,*.csproj,*.props |
Select-String -Pattern "Newtonsoft\.Json|JsonConvert|JObject|JArray|JToken|ExcludeAssets>runtime"検索結果がテストプロジェクト配下に出た場合は、そのプロジェクトファイルにNewtonsoft.Jsonの直接参照があるか確認します。
dotnet list package --include-transitive出力でNewtonsoft.Jsonが「Transitive」側にしか出ていない場合、そのプロジェクトは暗黙依存に頼っている可能性があります。.NET 11以降のVSTestでは、その前提で動かない可能性があるため、直接参照へ切り替えます。
テストプロジェクトにPackageReferenceを追加する
テストコードでNewtonsoft.Jsonを使っているなら、対象の.csprojに次のように追加します。バージョンは自社の依存関係ポリシーや既存プロジェクトに合わせて選びます。
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
</ItemGroup>コマンドで追加する場合は、次の形式です。
dotnet add path/to/YourTestProject.csproj package Newtonsoft.Json --version 13.0.3ここで大切なのは、「テストプロジェクトで使っているなら、テストプロジェクトに追加する」ことです。ソリューション内の別プロジェクトが参照しているから大丈夫、と判断しないでください。
Central Package Managementを使っている場合
Directory.Packages.propsでパッケージバージョンを集中管理している場合は、バージョンを中央に定義し、各テストプロジェクトではバージョンなしで参照します。
<!-- Directory.Packages.props -->
<Project>
<ItemGroup>
<PackageVersion Include="Newtonsoft.Json" Version="13.0.3" />
</ItemGroup>
</Project><!-- Test project .csproj -->
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" />
</ItemGroup>この方式なら、複数のテストプロジェクトでバージョンがばらつくのを防げます。CIで依存関係レビューや脆弱性チェックを行っているチームでは、こちらの方が管理しやすいでしょう。
ExcludeAssets=runtimeを使っている場合は特に注意
過去に「コンパイルでは使うが、実行時には別の場所からDLLが来る」と考えて、runtimeアセットを除外していたプロジェクトは要注意です。VSTestがNewtonsoft.Json.dllを出力先に置いてくれる前提だった場合、.NET 11以降は実行時に見つからなくなります。
修正前の例です。
<PackageReference Include="Newtonsoft.Json" Version="13.0.3">
<ExcludeAssets>runtime</ExcludeAssets>
</PackageReference>修正後は、実行時アセットを除外しない形にします。
<PackageReference Include="Newtonsoft.Json" Version="13.0.3" />ExcludeAssetsを残す必要がある場合でも、テスト実行時の出力フォルダーにNewtonsoft.Json.dllが確実に配置されるかを確認してください。ただし、手動コピーやテストランナー固有の配置に頼るより、通常はPackageReferenceで実行時アセットを含める方が保守しやすいです。
テストアダプターやデータコレクターを使っている場合の確認点
通常の単体テストだけでなく、カバレッジ収集、独自のデータコレクター、カスタムテストアダプターを使っている環境では、拡張機能側の依存関係も確認が必要です。
たとえば、データコレクターがNewtonsoft.Jsonを使っているのに、自身のパッケージで依存関係を宣言していない場合、VSTest更新後にロード時エラーが出る可能性があります。Microsoftのドキュメントでも、データコレクターやテストアダプターなどのテスト拡張が影響を受けるケースが説明されています。(GitHub)
利用者側でできる現実的な対応は次の3つです。
- 拡張機能の最新版が提供されていれば更新する
- 一時的にテストプロジェクトへ
Newtonsoft.Jsonを追加して回避できるか検証する - 問題の拡張機能を無効化し、テスト本体が通るか切り分ける
拡張機能の作者であれば、拡張機能のプロジェクト自身にNewtonsoft.Jsonを直接依存として追加してください。ユーザーのテストプロジェクトやVSTest本体に依存関係を肩代わりさせる設計は、今後の更新で壊れやすくなります。
VSTestの公開APIを直接使っている場合
一般的なxUnit、NUnit、MSTestのテストコードを書いているだけなら、この章の内容に該当することは少ないです。一方、VSTestの通信プロトコルやMicrosoft.VisualStudio.TestPlatform.CommunicationUtilitiesを直接扱うツールを作っている場合は、API削除の影響を確認してください。
ドキュメントでは、Newtonsoft.Json.Linq.JTokenベースの公開APIが削除されると説明されています。代表的には、Message.PayloadのJToken型、各種Converter、VersionedMessageなどが対象です。(GitHub)
この場合、Newtonsoft.Jsonを追加するだけでは、削除されたVSTest側のAPIは復活しません。自作ツールや拡張機能で該当APIを使っている場合は、VSTestの新しい通信APIやメッセージ処理に合わせてコードを修正する必要があります。
確認すべきキーワードは次のとおりです。
Microsoft.VisualStudio.TestPlatform.CommunicationUtilities
VersionedMessage
DefaultTestPlatformContractResolver
TestCaseConverter
TestResultConverter
TestRunStatisticsConverter
Newtonsoft.Json.Linq.JTokenこれらが自社コードに出てくる場合は、通常のテストプロジェクトより優先して検証してください。
Newtonsoft.JsonからSystem.Text.Jsonへ移行すべきか
今回の変更だけを理由に、アプリやテストコード全体をNewtonsoft.JsonからSystem.Text.Jsonへ急いで移行する必要はありません。VSTestの内部実装がSystem.Text.Jsonへ変わることと、あなたのテストコードが使うJSONライブラリは別の問題です。
実務上の判断は次のように分けるとよいでしょう。
| 状況 | おすすめの対応 |
|---|---|
テストコードで少量のJsonConvert.SerializeObjectだけ使っている | まずNewtonsoft.Jsonを明示参照。余裕があればSystem.Text.Json移行を検討 |
JObject、JToken、JsonPathを多用している | すぐ置き換えず、明示参照で安定化を優先 |
| 新規プロジェクトで単純なJSON入出力だけ行う | System.Text.Jsonを第一候補にする |
| 既存テストの期待値がJSON文字列に依存している | 移行時にプロパティ名、null、日付、列挙型、順序の差分をテスト |
| ライブラリや拡張機能を配布している | 依存関係を明示し、利用者環境に依存しない設計へ変更 |
Microsoft Learnの移行ガイドでも、System.Text.Jsonは性能、セキュリティ、標準準拠を重視しており、Newtonsoft.Jsonとの完全な機能互換を目指すものではないと説明されています。たとえばJsonPath、型名処理、一部の柔軟なデシリアライズ動作などは、単純な置換で済まない場合があります。(Microsoft Learn)
つまり、今回のVSTest変更への短期対応は「必要なプロジェクトにNewtonsoft.Jsonを明示追加する」ことです。System.Text.Jsonへの移行は、別タスクとして差分検証を行うべきです。
CI/CDで確認すべきポイント
ローカルのdotnet testだけ通っても、CIで失敗することがあります。特に、Azure DevOps、GitHub Actions、Visual Studio Testタスク、古いVisual Studio Test Platform Installerを使っている場合は、実行環境ごとのVSTestバージョン差に注意してください。
確認の順番は次のとおりです。
| 確認対象 | 見るべきポイント |
|---|---|
| ローカルCLI | dotnet testでビルドエラーやFileNotFoundExceptionが出ないか |
| Visual Studio | Test Explorerで同じテストが通るか |
| CI | テストタスクが使用する.NET SDK、VSTest、Visual Studioのバージョン |
| テスト結果 | TRXやCIのテストビューに拡張ロード失敗が出ていないか |
| 成果物 | テスト出力フォルダーに必要なDLLが配置されているか |
.NET 11 Preview 4やVisual Studio 18.8 Insidersを試す場合は、いきなり全CIを切り替えるのではなく、検証用ブランチや一部ジョブで先に試すのが安全です。global.jsonでSDKバージョンを固定しているチームは、意図せずPreview SDKへ切り替わらないように管理しましょう。
移行作業で失敗しやすいポイント
アプリ本体だけにPackageReferenceを追加してしまう
テストコードでJsonConvertを使っているなら、テストプロジェクト側にも参照が必要です。アプリ本体の依存関係をテストプロジェクトが常に自由に使えるとは考えない方が安全です。
古い暗黙依存を「たまたま動いている正常状態」と誤解する
Microsoft.NET.Test.Sdk経由でNewtonsoft.Jsonが見えていた状態は、テストプロジェクトの依存関係としては曖昧です。今後のSDK更新やテストプラットフォーム更新で同じような問題が起きる可能性があります。今回の対応を機に、テストプロジェクトが使うパッケージは明示する方針にすると保守しやすくなります。
System.Text.Jsonへの置換を同時に進めて原因を混ぜる
VSTest更新への対応と、JSONライブラリの移行を同時に行うと、失敗したときに原因が切り分けにくくなります。まずはNewtonsoft.Jsonの明示参照でテスト基盤を安定させ、その後に必要であればSystem.Text.Json移行を進めてください。
カスタム拡張の依存関係を見落とす
テストコード本体に問題がなくても、データコレクターやテストアダプターが失敗することがあります。エラーメッセージに拡張名が出ている場合は、テストコードではなく拡張側の依存関係を疑いましょう。
アップデート前チェックリスト
.NET 11 Preview 4以降、またはVisual Studio 18.8系のテスト環境へ進む前に、次の項目を確認してください。
- [ ] テストプロジェクト内で
Newtonsoft.Json、JsonConvert、JObject、JTokenを検索した - [ ] 使っているテストプロジェクトに
Newtonsoft.Jsonの直接PackageReferenceがある - [ ]
dotnet list package --include-transitiveで暗黙依存だけになっていないか確認した - [ ]
ExcludeAssetsにruntimeが含まれていないか確認した - [ ] データコレクター、テストアダプター、独自拡張の依存関係を確認した
- [ ]
dotnet test、Visual Studio Test Explorer、CIのすべてでテストした - [ ]
System.Text.Json移行を行う場合は、VSTest対応とは別タスクに分けた
まとめ：まずは暗黙依存を明示依存に直す
.NET 11のVSTest/Microsoft.NET.Test.SdkにおけるNewtonsoft.Json依存削除は、ほとんどのテストプロジェクトに大きな影響を与える変更ではありません。ただし、Microsoft.NET.Test.Sdkが持ち込む推移的依存に頼っていたプロジェクトでは、ビルドエラーや実行時のFileNotFoundExceptionとして問題が表面化します。
最初にやるべきことはシンプルです。テストプロジェクトでNewtonsoft.Jsonを使っているか検索し、使っているならそのプロジェクトに直接PackageReferenceを追加してください。次に、ExcludeAssets=runtimeやテスト拡張の依存関係を確認します。
今回の変更は、テスト基盤の依存関係を整理する良い機会でもあります。テストコードが必要とするライブラリは、VSTestや.NET SDKに頼らず、自分のプロジェクトで明示する。この方針に直しておけば、.NET 11以降のアップデートでも原因不明のテスト失敗を減らせます。
コメント