MENU

Visual Studioで.NET Frameworkをターゲット指定する方法｜2026年4月更新ポイントと実務チェック

Visual Studio

Visual Studioで「対象となる .NET Framework」を指定する作業は、単にドロップダウンを選ぶだけではありません。結論から言うと、2026年4月時点で押さえるべきポイントは、ターゲット フレームワークが使えるAPI・参照・IntelliSense・ビルド条件を左右すること、そして .NET 5以降では TargetFrameworks によるマルチターゲット運用が実務上さらに重要になっていることです。

なお、Microsoft公式ソースのGitHub履歴では2026年4月24日に該当ドキュメントへのコミットが確認できますが、内容は本文機能の大幅な追加ではなく、主にドキュメント管理メタデータの調整です。一方、Microsoft Learnページ上の表示では最終更新日は2026年3月17日となっており、実務で読むべき中心は「ターゲット フレームワークの指定方法」「複数フレームワーク対応」「参照エラーの回避」です。(GitHub)

目次

Visual Studioの最新動向: Specify the targeted .NET Frameworksで何が変わったか

Microsoft Learnの「Specify the targeted .NET Frameworks – Visual Studio (Windows)」は、Visual Studioでプロジェクトが対象にする .NET のバージョンを指定する方法を説明する公式ドキュメントです。ターゲット フレームワークを指定すると、そのバージョンで利用できる機能だけをアプリケーションが使うように制御しやすくなります。特に .NET Framework アプリでは、実行先PCにインストールされている .NET Framework のバージョンとの互換性が重要です。(Microsoft Learn)

2026年4月24日のGitHub履歴を見ると、該当ファイルには2件のコミットがあります。1件は manager から ms.manager へのメタデータ表記調整、もう1件は自動挿入されるメタデータを整理する変更です。つまり、Visual Studioのターゲット フレームワーク指定機能そのものが4月24日に大きく変わった、というよりも、公式ドキュメントの管理情報が整備されたと見るのが正確です。(GitHub)

ただし、記事として重要なのは「変更が小さいから読む価値がない」という話ではありません。むしろ、Visual Studioのターゲット フレームワーク設定は、開発者、DevOpsエンジニア、プラットフォームチームが同じ認識で運用しないと、ビルド失敗・参照エラー・本番環境での動作不一致につながりやすい領域です。

Visual Studioでターゲット フレームワークを指定する意味

Visual Studioのターゲット フレームワーク設定は、プロジェクトが「どの .NET API セットを前提にビルドされるか」を決める設定です。たとえば net8.0 を対象にするプロジェクトと net10.0 を対象にするプロジェクトでは、使えるAPI、NuGetパッケージの解決、ビルド時の互換性チェックが変わります。

Microsoftの .NET公式ドキュメントでは、ターゲット フレームワークはTarget Framework Moniker、つまりTFMで表されます。2026年4月時点の公式情報では、代表的な最新安定バージョンとして .NET 10 は net10.0、.NET 9 は net9.0、.NET 8 は net8.0、.NET Framework 4.8.1 は net481 と示されています。(Microsoft Learn)

Visual Studioの設定画面で見ると単なる選択項目に見えますが、実際には次のような範囲に影響します。

影響する領域具体的な影響
API利用対象バージョンで使えないAPIはIntelliSenseやビルドで制限される
参照設定対象フレームワークに合わないアセンブリ参照は解決できない場合がある
NuGetパッケージ内のどのTFM向けアセットを使うかが変わる
ビルド対象バージョンに応じたコンパイラオプションやビルド条件が使われる
実行環境.NET Frameworkアプリでは実行先に互換バージョンが必要になる

特に注意したいのは、ターゲット フレームワークを指定しても、アプリが必ず正しく動作するとは限らない点です。Microsoft Learnでも、フレームワーク ターゲット設定は実行の正しさを保証するものではなく、対象バージョンでテストする必要があると明記されています。(Microsoft Learn)

既存プロジェクトでターゲット フレームワークを変更する手順

Visual Studioで既存のC#、Visual Basic、F#プロジェクトのターゲット .NET バージョンを変更する場合、基本操作はプロジェクトのプロパティから行います。Microsoft Learnでは、ソリューション エクスプローラーで対象プロジェクトを右クリックし、プロパティの「アプリケーション」タブから「ターゲット フレームワーク」を選択する流れが説明されています。変更後、確認ダイアログが出た場合は承認し、プロジェクトが再読み込みされると選択した .NET バージョンが対象になります。(Microsoft Learn)

実務では、次の順番で進めると失敗を減らせます。

手順作業確認ポイント
1変更用ブランチを作成する参照やパッケージ変更を安全に戻せる状態にする
2SDKまたはDeveloper Packを確認する対象バージョンの参照アセンブリが入っているか確認
3Visual Studioのプロパティで変更するC#、VB、F#は「アプリケーション」タブから変更
4ビルドする参照エラー、NuGet復元エラー、警告を確認
5実行テストを行う対象OS、実行端末、CI環境で再現確認する
6CI/CD設定を更新するglobal.json、ビルドイメージ、SDKインストール手順を見直す

UWPアプリについては注意が必要です。Microsoft Learnでは、UWPアプリ作成後は対象となるWindowsまたは .NET のバージョンを変更できないとされています。既存資産を移行する場合は、単純なターゲット変更ではなく、新しいプロジェクト構成や移行計画として扱うべきです。(Microsoft Learn)

.NET 5以降で重要なTargetFrameworksによるマルチターゲット

.NET 5以降では、1つのプロジェクトを複数のフレームワーク向けにビルドできます。Visual Studioの公式ドキュメントでは、プロジェクトファイルを手動で編集し、単数形の TargetFramework を複数形の TargetFrameworks に置き換え、TFMをセミコロン区切りで指定する方法が示されています。(Microsoft Learn)

<TargetFrameworks>net8.0;net9.0</TargetFrameworks>

2026年時点の実務では、公式ドキュメントの例をそのまま使うのではなく、自社のサポート方針に合わせてTFMを選ぶことが重要です。たとえば新規の長期運用アプリなら net10.0 を検討し、既存顧客や社内システムが .NET 8 に依存している場合は、移行期間だけ net8.0;net10.0 のようなマルチターゲット構成を使う選択肢があります。

複数ターゲットにすると、1つのライブラリを複数の実行環境に配布しやすくなります。一方で、条件付きコード、NuGet依存関係、CIのビルドマトリクスが複雑になります。単に「複数指定できるから便利」と考えるのではなく、次のように使い分けると判断しやすくなります。

ケース推奨しやすい構成理由
新規の社内Web APInet10.0長期サポートを前提にしやすい
既存 .NET 8 アプリの段階移行net8.0;net10.0移行期間中に互換性を検証できる
.NET Framework利用者も使うライブラリnetstandard2.0 または複数TFM古い利用者との互換性を確保しやすい
Windowsデスクトップアプリnet10.0-windows などWinFormsやWPFなどWindows固有APIを使うため
レガシー .NET Frameworkアプリ現行TFM維持または net481 への整理実行先PCや業務システムの制約を受けやすい

.NET公式のサポートポリシーでは、2026年4月時点で .NET 10 はLTSとして2028年11月14日まで、.NET 9と .NET 8 はいずれも2026年11月10日までサポート対象とされています。新規開発や長期運用では、サポート期限をターゲット フレームワーク選定の判断材料に含めるべきです。(Microsoft)

Visual StudioのUIだけでなくプロジェクトファイルも確認する

Visual Studioの画面でターゲット フレームワークを変更できても、最終的にはプロジェクトファイルの設定がビルドの根拠になります。Microsoft Learnでは、対象フレームワークに応じてプロジェクトファイル上の表現が異なる例が示されています。たとえば .NET アプリでは <TargetFramework>net9.0</TargetFramework>、.NET Standardでは <TargetFramework>netstandard2.0</TargetFramework>、従来型の .NET Frameworkアプリでは <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion> のように表されます。(Microsoft Learn)

実務でよくある混乱は、Visual Studio上では「.NET Framework 4.8.1」のように見えているのに、SDKスタイルのプロジェクトやNuGet互換性の文脈では net481 のようなTFMで扱われることです。チーム内で会話するときは、「Visual Studio画面での表示名」と「csproj上のTFM」を分けて確認すると、認識違いを防げます。

確認すべきファイルは主に次の3つです。

<!-- .csprojの例：単一ターゲット -->
<TargetFramework>net10.0</TargetFramework>
<!-- .csprojの例：複数ターゲット -->
<TargetFrameworks>net8.0;net10.0</TargetFrameworks>
// global.jsonの例：CIや開発端末で使うSDKを揃える
{
  "sdk": {
    "version": "10.0.100"
  }
}

global.json はVisual Studioの公式ページの主題ではありませんが、DevOpsやプラットフォームチームにとっては重要です。開発者のPCではビルドできるのにCIで失敗する場合、ターゲット フレームワークではなく、CIエージェントに入っているSDKやDeveloper Packが不足していることがあります。

参照エラーが出る理由と解決の考え方

ターゲット フレームワーク変更後に最も起きやすい問題は、参照エラーです。Microsoft Learnでは、対象の .NET とは異なるバージョンの .NET への参照がコードに含まれている場合、コンパイル時または実行時にエラーメッセージが表示されることがあると説明されています。解決には参照の修正が必要です。(Microsoft Learn)

よくある原因は次の通りです。

症状よくある原因対処
型やメソッドが見つからない新しい .NET でしか使えないAPIを古いTFMで使っているTFMを上げるか、代替APIを使う
NuGet復元に失敗するパッケージが対象TFMをサポートしていないパッケージ更新、別パッケージ検討、マルチターゲット化
参照アセンブリが解決できないDeveloper PackやSDKが未インストールビルド環境に必要なSDK・Developer Packを入れる
Visual Studioでは動くがCIで落ちるCIのSDKバージョンが違うglobal.json とCIイメージを揃える
実行時に例外が出るビルドは通るが実行環境に互換ランタイムがない実行端末・コンテナ・サーバーのランタイムを確認

.NET Frameworkプロジェクトでは、対象フレームワークに関係しないシステムアセンブリが参照ダイアログで無効化され、誤って追加されないように制御されます。対象より高いフレームワークに属する参照は解決できないため、その参照が必要ならプロジェクトの .NET Frameworkターゲットを見直す必要があります。(Microsoft Learn)

開発者・DevOps・プラットフォームチーム別の見るべきポイント

開発者が確認すべきこと

開発者は、まず自分のコードが対象TFMで本当に使えるAPIだけを使っているかを確認します。Visual Studioは、対象バージョンで使えない機能をIntelliSenseやダイアログ上でフィルターします。これは不具合ではなく、ターゲット フレームワークに合わせた正常な制御です。(Microsoft Learn)

特にマルチターゲットでは、条件付きコンパイルが必要になることがあります。

#if NET10_0_OR_GREATER
    // .NET 10以降で使う処理
#else
    // 古いターゲット向けの処理
#endif

ただし、条件付きコードを増やしすぎると保守性が落ちます。差分が小さい場合はマルチターゲットが有効ですが、実装が大きく分岐するなら、ライブラリ分割やメジャーバージョン分けを検討したほうが安全です。

DevOpsエンジニアが確認すべきこと

DevOpsエンジニアは、Visual Studioの設定よりもビルド環境の再現性を重視する必要があります。ローカルのVisual Studioではビルドできても、CIエージェントに対象SDKがなければ失敗します。

最低限、次の項目をチェックしてください。

  • CIエージェントに対象 .NET SDK が入っているか
  • .NET Frameworkの場合、必要なDeveloper Packが入っているか
  • dotnet build -f net10.0 のように対象TFMを明示してビルドしているか
  • 複数TFMでは各ターゲットごとにテストを実行しているか
  • コンテナイメージやデプロイ先ランタイムが対象TFMに対応しているか

マルチターゲットのライブラリでは、dotnet test だけで安心しないほうがよいです。必要に応じて -f net8.0、-f net10.0 のように対象フレームワーク別にテストを分けると、片方のTFMだけで発生する不具合を見つけやすくなります。

プラットフォームチームが確認すべきこと

プラットフォームチームは、個別プロジェクトの都合だけでなく、組織全体のターゲット フレームワーク方針を整える役割があります。

たとえば2026年4月時点では、.NET 10がLTSとして長期運用の候補になります。一方で、既存の .NET 8 や .NET Frameworkアプリがすぐに消えるわけではありません。サポート期限、顧客環境、セキュリティ更新、社内標準SDKを踏まえて、次のような方針を明文化すると運用しやすくなります。

方針項目例
新規開発の標準TFM原則 net10.0
Windows専用アプリnet10.0-windows を基本にする
既存 .NET 8サポート期限までに移行計画を作る
.NET Framework新規採用は避け、保守・移行対象として扱う
共通ライブラリ利用者に応じて netstandard2.0 または複数TFMを検討
CI標準SDKバージョン、ビルドコマンド、テスト対象TFMを定義する

失敗しやすいポイント

Visual Studioのターゲット フレームワーク指定で失敗しやすいのは、設定変更を「移行完了」と誤解することです。ターゲットを変更してビルドが通っても、依存パッケージ、実行環境、配布方法、テスト範囲が追従していなければ、本番で問題が起きます。

特に次の点は見落とされがちです。

失敗パターンなぜ問題になるか回避策
Visual Studioだけで変更してCIを更新しないCIでSDK不足や復元エラーが起きるCI定義とSDKバージョンを同時に更新する
マルチターゲットにしたが片方しかテストしない特定TFMだけの不具合を見逃すTFM別にビルド・テストする
サポート期限を見ずにTFMを選ぶ数か月後に再移行が必要になる.NETサポートポリシーを確認する
.NET Frameworkアプリを一気に最新 .NET へ移すAPI差分や実行環境差分が大きい段階移行、互換性調査、テスト計画を作る
参照エラーを場当たり的に直すパッケージ互換性が崩れる依存関係ツリーを確認して整理する

ターゲット フレームワーク変更は、開発環境の設定変更ではなく、アプリケーションのサポート範囲を変更する作業です。この視点を持つだけで、移行時の判断がかなり明確になります。

2026年4月時点での実務的な進め方

Visual Studioでターゲット .NET Frameworkを指定・変更する場合は、まず「何をサポートするためのターゲットなのか」を決めてください。新しいAPIを使いたいのか、古い利用者との互換性を維持したいのか、長期サポートを優先したいのかで、選ぶTFMは変わります。

実務では、次の順番で進めるのがおすすめです。

  1. 現在の .csproj にある TargetFramework または TargetFrameworks を確認する
  2. 実行環境、顧客環境、CI環境に必要なSDK・ランタイムを洗い出す
  3. .NETサポート期限を確認して候補TFMを決める
  4. Visual Studioまたはプロジェクトファイルでターゲットを変更する
  5. 参照、NuGet、条件付きコードを整理する
  6. 対象TFMごとにビルド・テスト・デプロイ検証を行う
  7. チーム標準としてTFM、SDK、CI設定をドキュメント化する

2026年4月24日の公式ソース更新履歴は、本文機能の大きな変更ではありません。しかし、Visual Studioのターゲット フレームワーク指定は、.NET 10時代の開発基盤を整えるうえで見直す価値があります。まずは各プロジェクトのTFMを棚卸しし、サポート期限・実行環境・CI設定の3点がそろっているかを確認するところから始めるとよいでしょう。

Visual Studio
.NET Framework .NET Visual Studio MSBuild TargetFramework

この記事を書いた人

佐藤健司のアバター 佐藤健司

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

関連記事

コメント

コメントする

目次