これまで
.net standard 2.x はランタイムを支える BCL でランタイムバージョンに左右されないので多用していた。
特にUnityでのモジュールで区切る時必然的にターゲットは netstandard 2.1 だった
dotnet アプリケーションならむしろ TargetFramework は dotnetx.x
GPT5.5の見解
結論として、あなたの用途が「自分のアプリ群の内部モジュール」で、実行アプリがすべて .NET 10 なら、モジュール側も net10.0 で問題ありません。むしろ自然です。
Microsoft 公式ガイドでも、アプリを複数プロジェクトに分割している「app components」は net10.0 を推奨し、同じ .NET バージョンに揃えると同じ BCL/API 前提で扱える、とされています。(Microsoft Learn)
判断基準
net10.0 でよいケース
以下なら netstandard2.1 に縛る理由は薄いです。
-
CLI / デスクトップアプリ本体が
net10.0 -
モジュールが外部公開用 NuGet ではなく、同一ソリューション内の構成要素
-
.NET Framework / Unity / Xamarin / 古い Mono などから利用する予定がない
-
最新 C# / 最新 BCL / trimming / AOT / パフォーマンス改善の恩恵を受けたい
この場合、4層アーキテクチャ上の「Domain」「Application」「Infrastructure」などは、技術的にはライブラリでも、配布単位としてはアプリケーション・コンポーネントです。したがって net10.0 統一でよいです。
netstandard2.1 を残す意味
netstandard は「複数の .NET 実装で使える API 仕様」です。つまり、netstandard2.1 にすると使える API を意図的に制限し、その標準を実装する環境で動くことを狙います。(Microsoft Learn)
ただし、重要なのは .NET Standard 2.1 は .NET Framework をサポート対象に含めない点です。広い互換性、特に .NET Framework 対応が目的なら、公式ガイドは netstandard2.0 を検討対象にしています。(Microsoft Learn)
つまり、
netstandard2.1 = 互換性のための選択としては中途半端になりやすい
netstandard2.0 = .NET Framework も含めた広い互換性向け
net10.0 = 現代 .NET 前提のアプリ内モジュール向けという整理です。
例外的に netstandard を選ぶケース
外部公開ライブラリなら話が変わります。
-
NuGet 公開して不特定多数に使ってもらう
-
.NET Framework 利用者も想定する
-
Unity / 古い環境 / 特殊ランタイムを想定する
-
ライブラリとして長期互換性を重視する
この場合は、netstandard2.0 + net10.0 のマルチターゲットが候補です。公式ガイドでも、新しいライブラリは net8.0 以上から始め、広範な互換性や .NET Framework 対応が必要なら netstandard2.0 を含める、という方向です。(Microsoft Learn)
例：
<TargetFrameworks>netstandard2.0;net10.0</TargetFrameworks>あなたの構成への見解
現在の構成が、
CLI / Desktop App: net10.0
Domain/Application/Infrastructure 等: netstandard2.1なら、私なら基本的にこうします。
CLI / Desktop App: net10.0
Domain: net10.0
Application: net10.0
Infrastructure: net10.0理由は、これらが「汎用ライブラリ」ではなく「アプリケーションを構成する内部モジュール」だからです。
ただし、Domain 層だけを将来 NuGet 化したい、別ランタイムからも使わせたい、という明確な予定があるなら、その層だけ netstandard2.0 またはマルチターゲットを検討します。
最終判断
2026年時点で、新規開発のアプリ内モジュールを netstandard2.1 にする積極的理由は弱いです。
おすすめは次です。
内部モジュール: net10.0
外部公開・広範互換ライブラリ: netstandard2.0 + net10.0
netstandard2.1: 明確な対象ランタイムがある場合のみ4層アーキテクチャ上の分離は、TargetFramework ではなく依存方向・参照制約・インターフェース境界で守るのが本筋です。
