.NET Frameworkとは｜.NETとの違い・バージョン確認・サポート期限

「.NET」という名前は、2002年からの Windows 専用の .NET Framework と、2016年に .NET Core として始まり、2020年の 5 から「.NET」と呼ばれるようになったクロスプラットフォームの .NET の両方を指すことがあります。まず関係を図で示します。

flowchart TD
    A[.NET Framework<br>1.0〜4.8.1<br>Windows 専用] -->|4.8.1 で<br>機能追加は終了| F[保守のみ]
    B[.NET Core<br>1.0〜3.1] -->|Core を外す| C[.NET 5〜9]
    C --> G[.NET 10 LTS<br>Windows・Linux・macOS]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（x64・2コア）に、Ubuntu の公式リポジトリから apt で dotnet-sdk-10.0（SDK 10.0.113・ランタイム 10.0.13）と dotnet-runtime-8.0（8.0.32）などを入れ、テレメトリーを止める環境変数 DOTNET_CLI_TELEMETRY_OPTOUT=1 を最初の dotnet 実行より前に設定して使いました。コンソールアプリの作成・実行、net8.0 と net10.0 の複数ターゲット、5通りの publish（大きさと起動時間の実測）、net48 を指定したときのエラー、Linux でのレジストリ API の動き、存在しないランタイムを指定したときのエラーを実際に動かしています。NuGet（パッケージの取得）はこの環境では通信が止められていたため、外部パッケージを使わない例だけで書きました。Windows の操作（レジストリ・PowerShell・Windows の機能・.NET Framework 3.5）は手元で動かせないため、Microsoft Learn と dotnet.microsoft.com の公式ドキュメントで確かめた範囲だけを書いています。図は mermaid で描画を確かめました（確認日 2026年10月29日）。

.NET Frameworkとは（わかりやすく）

この節では、.NET Framework が何をするもので、なぜパソコンに入っているのかが分かります。

.NET Framework は、Windows 上でアプリを作って動かすためのソフトウェア開発フレームワークです。 Microsoft の公式ページは、.NET Framework を「.NET のオリジナル実装」と説明し、新しい開発には .NET 8 以降を使うよう勧めています。そのうえで、.NET Framework をダウンロードすべきなのは「作っているアプリが必要とする」か「使っているアプリが必要とする」場合だけ、と書いています。

利用者の立場では、.NET Framework で作られたアプリ（業務ソフト・会計ソフト・社内ツール・一部のゲームなど）を動かすための部品です。Windows 10・11 には 4.8 か 4.8.1 があらかじめ入っていて、Windows Update で更新されます。アプリの起動時に「.NET Framework 3.5 が必要です」と出るのは、そのアプリが以前の版の .NET Framework を前提に作られているためです。

開発者の立場では、C#・Visual Basic・F# で書いたプログラムを実行する仕組み（CLR）と、ファイル・ネットワーク・データベース・画面などを扱う大量の部品（クラスライブラリ）のセットです。Windows フォーム・WPF・ASP.NET Web Forms・WCF などのアプリがこの上で動いています。

読み方は「ドットネット フレームワーク」です。英語の「framework（枠組み）」のとおり、アプリが共通で使う土台をまとめたもの、と考えると分かりやすくなります。

.NET Frameworkと.NETの違い（一覧表）

この節では、.NET Framework と .NET（旧 .NET Core）の違いが、一覧と図で分かります。

いちばん大きな違いは「動く OS」と「今後も新しい機能が入るか」です。 Microsoft は、すべての新しい機能は .NET で作られると書いています。.NET Framework は Windows の一部として保守が続きます。

共通点もあります。どちらも C# で書き、コンパイルすると中間言語（CIL）の .dll・.exe ができ、実行時に CLR がその場で機械語に直して（JIT コンパイル）動かします。多くのクラス（System.String・List<T>・LINQ など）は同じ名前・同じ使い方です。両方から使えるライブラリを作るための共通の仕様が .NET Standard で、netstandard2.0 で作ったライブラリは .NET Framework 4.6.1 以降と .NET の両方から参照できます。

.NETの歴史と名前（.NET Core・.NET 5・.NET 10）

この節では、「.NET とは」で検索したときに混乱しやすい名前の移り変わりが分かります。

今「.NET」と書かれていたら、多くは .NET 5 以降のクロスプラットフォームの .NET を指します。 公式サイトは .NET を「Microsoft がサポートする無料のオープンソースのアプリケーション プラットフォーム」と説明しています。

.NET Frameworkの仕組み（CLR・クラスライブラリ・CIL）

この節では、.NET Framework の2つの主な部品と、プログラムが動くまでの流れが分かります。

.NET Framework は「共通言語ランタイム（CLR）」と「クラスライブラリ」の2つでできています。

この流れは .NET も同じです。手元の .NET 10 で dotnet new console を実行すると、次の2つのファイルができました。

$ dotnet new console -n HelloNet -o HelloNet
The template "Console App" was created successfully.

Processing post-creation actions...
Restoring /dev/shm/t69/work/HelloNet/HelloNet.csproj:
  Determining projects to restore...
  Restored /dev/shm/t69/work/HelloNet/HelloNet.csproj (in 119 ms).
Restore succeeded.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

TargetFramework（TFM）がどの実装・版向けかを決めます。.NET Framework 4.8 向けなら net48、.NET 8 なら net8.0 です。

C# の版はターゲットで決まる

C# の版は、既定ではターゲットのフレームワークで決まります。ソースに #error version と1行だけ書いてビルドすると、コンパイラが使っている版を表示します。net8.0 と net10.0 の両方をターゲットにしてビルドした結果です。

Program.cs(1,8): error CS8304: Compiler version: '5.0.0-2.26504.104 (4099f839)'. Language version: 12.0.
Program.cs(1,8): error CS8304: Compiler version: '5.0.0-2.26504.104 (4099f839)'. Language version: 14.0.

同じコンパイラでも、net8.0 では C# 12、net10.0 では C# 14 になりました。SDK に含まれる設定ファイル（Roslyn/Microsoft.CSharp.Core.targets）を見ると、.NET Framework 向け（.NET Core 3.0 未満・.NET Standard 2.1 未満を含む）の既定は C# 7.3 と決められていました。Microsoft Learn「C# 言語のバージョン管理」も、既定の版はターゲットに合わせて決まり、ターゲットより新しい C# の使用はサポートされないと書いています。.NET Framework のプロジェクトで新しい書き方（record・ファイルスコープの名前空間など）がエラーになるのはこのためです。

.NET Frameworkのバージョン一覧とWindowsの対応

この節では、.NET Framework の各版がいつ出て、どの Windows に最初から入っているかが分かります。

4.x はすべて同じ CLR 4 の上に載るため、新しい 4.x を入れると前の 4.x は置き換わります（上書き更新）。 一方、3.5（CLR 2.0）は 4.x と並べて入れられます。公式ページは「4.7.2 と 3.5 が入った環境に 4.8 を入れると、4.7.2 が 4.8 に更新され、3.5 はそのまま残る」と例を挙げています。

表は Microsoft Learn「.NET Framework のバージョンと依存関係」と、dotnet.microsoft.com「.NET Framework とは」のリリース履歴から作りました（2026年10月29日時点）。4.8.1 は Windows 11（22000）と Windows 10（20H2〜22H2）、Windows Server 2022 には後から入れられます。また、Visual Studio 2022 以降には .NET Framework 4.0〜4.5.1 向けの部品が含まれないため、4.5.1 以前向けのビルドには Visual Studio 2019 以前が要る、と公式に書かれています。

.NET Frameworkのバージョン確認方法（レジストリ・PowerShell）

この節では、Windows に入っている .NET Framework の版を確かめる方法が、Microsoft Learn の手順どおりに分かります。

4.5 以降の版は、レジストリの Release という値で判定します。 場所は次のキーです。Full のキーが無ければ 4.5 以降は入っていません。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full

PowerShell で確かめる（いちばん手早い方法）

Microsoft Learn に載っているコマンドです。1行目は「4.6.2 以上か」を True・False で返します。

(Get-ItemPropertyValue -LiteralPath 'HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' -Name Release) -ge 394802

版の名前まで出すには、Release の値を範囲で振り分けます（公式の例をそのまま載せます）。

$release = Get-ItemPropertyValue -LiteralPath 'HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' -Name Release
switch ($release) {
    { $_ -ge 533320 } { $version = '4.8.1 or later'; break }
    { $_ -ge 528040 } { $version = '4.8'; break }
    { $_ -ge 461808 } { $version = '4.7.2'; break }
    { $_ -ge 461308 } { $version = '4.7.1'; break }
    { $_ -ge 460798 } { $version = '4.7'; break }
    { $_ -ge 394802 } { $version = '4.6.2'; break }
    { $_ -ge 394254 } { $version = '4.6.1'; break }
    { $_ -ge 393295 } { $version = '4.6'; break }
    { $_ -ge 379893 } { $version = '4.5.2'; break }
    { $_ -ge 378675 } { $version = '4.5.1'; break }
    { $_ -ge 378389 } { $version = '4.5'; break }
    default { $version = $null; break }
}

if ($version) {
    Write-Host -Object ".NET Framework Version: $version"
} else {
    Write-Host -Object '.NET Framework Version 4.5 or later is not detected.'
}

レジストリエディターで確かめる

Environment.Version は Framework の版ではない

C# で Environment.Version を表示すると、.NET Framework 4.x では 4.0.30319.xxxxx のような CLR の版が出ます。公式は「4.5 以降では、CLR の版を調べるのに Environment.Version を使わず、レジストリを調べる」よう注意しています。.NET（5 以降）では事情が違い、手元の .NET 8 と .NET 10 では Environment.Version がそのままランタイムの版（8.0.32・10.0.13）を返しました（次の節で原文を載せます）。

同じコードを Linux で動かすとどうなるか

公式のレジストリを読むコードを、.NET 10 のコンソールアプリにして Linux で動かしました。

using Microsoft.Win32;

const string subkey = @"SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\";
Console.WriteLine($"Registry.LocalMachine is null: {Registry.LocalMachine is null}");
try
{
    using RegistryKey? ndpKey = Registry.LocalMachine.OpenSubKey(subkey);
    Console.WriteLine($"Release = {ndpKey?.GetValue("Release")}");
}
catch (Exception ex)
{
    Console.WriteLine($"{ex.GetType().FullName}: {ex.Message}");
}

warning CA1416: This call site is reachable on all platforms. 'Registry.LocalMachine' is only supported on: 'windows'.
warning CA1416: This call site is reachable on all platforms. 'RegistryKey.OpenSubKey(string)' is only supported on: 'windows'.
warning CA1416: This call site is reachable on all platforms. 'RegistryKey.GetValue(string?)' is only supported on: 'windows'.

Registry.LocalMachine is null: True
System.NullReferenceException: Object reference not set to an instance of an object.

ビルドは警告（CA1416）だけで通り、実行すると Linux では Registry.LocalMachine が null で、NullReferenceException になりました。 .NET は Linux でも動きますが、Windows だけの API はそのままでは動きません。if (OperatingSystem.IsWindows()) で囲むと CA1416 の警告は消えます。

.NETのバージョン確認方法（dotnet --list-sdks）

この節では、.NET（5 以降）の SDK とランタイムの版を確かめるコマンドと、その出力の読み方が分かります。

.NET はレジストリではなく、dotnet コマンドで確かめます。 Windows でもコマンドプロンプトや PowerShell で同じコマンドが使えます。手元の出力です。

$ dotnet --list-sdks
10.0.113 [/usr/lib/dotnet/sdk]

$ dotnet --list-runtimes
Microsoft.AspNetCore.App 10.0.13 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 8.0.32 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.13 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

SDK の版（10.0.113）とランタイムの版（10.0.13）は番号の付け方が違います。SDK の 3桁目の「1xx」は SDK の機能の帯、下2桁が修正の回数です。dotnet --info では、SDK・ランタイム・OS・環境変数までまとめて表示されます。

$ dotnet --info
.NET SDK:
 Version:           10.0.113
 Commit:            4099f83977
 Workload version:  10.0.100-manifests.da132f47
 MSBuild version:   18.0.36+4099f8397

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  24.04
 OS Platform: Linux
 RID:         ubuntu.24.04-x64
 Base Path:   /usr/lib/dotnet/sdk/10.0.113/

Windows での入れ方は、Microsoft Learn「Windows に .NET をインストールする」に、WinGet のパッケージ ID が載っています（管理者として実行）。

winget install Microsoft.DotNet.SDK.10
winget install Microsoft.DotNet.DesktopRuntime.10
winget install Microsoft.DotNet.AspNetCore.10

同じページによると、SDK を入れればランタイムは別に入れなくてよく、Windows ですべての .NET アプリを動かすには ASP.NET Core ランタイムとデスクトップ ランタイムの両方を入れます。Visual Studio は独自に .NET を管理し、.NET SDK 10 は Visual Studio 2026（18.0）以降が必要です。

サポート期限の一覧（.NET Framework・.NET 8/9/10）

この節では、.NET Framework と .NET の各版がいつまでサポートされるかと、期限の決まり方が分かります。

.NET 8 と .NET 9 のサポートは2026年11月10日に終わります（この記事の更新日から12日後）。 終わったあとはセキュリティ修正が出ないため、.NET 10 へ上げる計画が要ります。

.NET の決まりは公式の「.NET および .NET Core の公式サポート ポリシー」にあり、LTS は一般提供から3年、STS は2年です（.NET 9 から STS が18か月から24か月に延びたため、.NET 8 と .NET 9 の終了日がそろいました）。最後の6か月はセキュリティ修正だけの「メンテナンス」期間です。同じページの最新の修正版は 10.0.14・9.0.22・8.0.33（2026年10月25日）で、手元の Ubuntu のパッケージは 10.0.13・8.0.32 と一つ前でした。Linux のディストリビューションの パッケージは、Microsoft の公開から少し遅れて届くことがあります。

.NET Framework は「コンポーネント ライフサイクル ポリシー」に従い、入っている Windows のサポートが続く間はサポートされます。4.5.2・4.6・4.6.1 は、SHA-1 の証明書で署名されていたことを理由に2022年4月26日で終わりました。

• 1サーバーに入っているランタイムを一覧にする各サーバーで dotnet --list-runtimes。8.0.x・9.0.x が残っていないか
• 2プロジェクトの TargetFramework を grep するnet8.0・net9.0 のままのプロジェクトを洗い出す
• 3コンテナのベースイメージの版を見るDockerfile の FROM の 8.0・9.0 のタグ
• 4net10.0 でビルドとテストを通す破壊的変更は公式の「.NET 10 の破壊的変更」で確かめる
• 5.NET Framework 4.6.2 のアプリを 4.8.1 で試す4.x は互換性が高く、公式は 4.x のアプリは 4.8.1 で動くと書いている

.NET Framework 3.5を有効にする方法（Windows 10・11）

この節では、「.NET Framework 3.5 が必要です」と出たときに 3.5 を有効にする手順が、Microsoft Learn の記述どおりに分かります。

Windows 10 と Windows 11（25H2 以前）では、3.5 は「Windows の機能」として有効にします。 3.5 には 2.0 と 3.0 も含まれます。

アプリを起動したときに表示される構成のダイアログで「この機能をダウンロードしてインストールする」を選んでも、同じように有効になります（インターネット接続が要ります）。

Windows 11 26H1 以降は単体のインストーラー

Microsoft Learn「Windows 11 への .NET Framework 3.5 のインストール」によると、Windows 11 26H1（ビルド 28000）以降では、3.5 は単体のインストーラーとしてだけ提供され、Windows の機能としては入れられません。 ASP.NET 3.5・.NET 機能拡張 3.5・WCF の HTTP／非 HTTP アクティブ化の各オプションも削除されます。インストーラーは指定された版の Windows でだけ動きます。Windows の版は winver.exe か、設定の「バージョン情報」で確かめられます。

インストール中に出るエラーとして、公式ページには 0x800f0906・0x800f0907・0x800f081f・0x800F0922 が挙げられています。4.x を入れても 3.5 の代わりにはならない点に注意します（3.5 と 4.x は CLR が別です）。

Linuxで.NETを動かす（.NET SDKのインストールと実行結果）

この節では、.NET Framework では不可能な「Linux で C# のアプリを動かす」ことを、.NET 8 と .NET 10 で実際に行った結果が分かります。

Ubuntu 24.04 では、Ubuntu 公式のリポジトリから apt で .NET SDK を入れられます。 SDK の最初の実行で使用状況の送信（テレメトリー）が有効にならないよう、先に環境変数を設定しました。設定ファイルやキャッシュの置き場所も作業用のフォルダーに向けています。

export DOTNET_CLI_TELEMETRY_OPTOUT=1      # 最初の dotnet 実行より前に
export DOTNET_NOLOGO=1
export DOTNET_CLI_HOME=/dev/shm/t69/clihome
export NUGET_PACKAGES=/dev/shm/t69/nuget

sudo apt-get install -y dotnet-sdk-10.0 dotnet-runtime-8.0 dotnet-targeting-pack-8.0

dotnet-sdk-10.0 を指定すると、ランタイム・ASP.NET Core ランタイム・テンプレート・NativeAOT 用の部品など16個のパッケージが一緒に入りました（.NET 8 向けのビルド用に、あとで aspnetcore-targeting-pack-8.0 と dotnet-apphost-pack-8.0 も追加）。テレメトリーの止め方は Microsoft Learn「.NET SDK と .NET CLI のテレメトリ」に「DOTNET_CLI_TELEMETRY_OPTOUT 環境変数を 1 または true に設定」と書かれています。

実行環境を表示するプログラム

using System.Runtime.InteropServices;

Console.WriteLine($"FrameworkDescription : {RuntimeInformation.FrameworkDescription}");
Console.WriteLine($"Environment.Version  : {Environment.Version}");
Console.WriteLine($"OSDescription        : {RuntimeInformation.OSDescription}");
Console.WriteLine($"RuntimeIdentifier    : {RuntimeInformation.RuntimeIdentifier}");
Console.WriteLine($"ProcessArchitecture  : {RuntimeInformation.ProcessArchitecture}");
Console.WriteLine($"IsWindows            : {OperatingSystem.IsWindows()}");

csproj を <TargetFrameworks>net8.0;net10.0</TargetFrameworks>（複数形）にすると、1回のビルドで両方の版向けの出力ができます。それぞれを動かした結果です。

$ dotnet bin/Debug/net8.0/HelloNet.dll
FrameworkDescription : .NET 8.0.32
Environment.Version  : 8.0.32
OSDescription        : Ubuntu 24.04.5 LTS
RuntimeIdentifier    : ubuntu.24.04-x64
ProcessArchitecture  : X64
IsWindows            : False

$ dotnet bin/Debug/net10.0/HelloNet.dll
FrameworkDescription : .NET 10.0.13
Environment.Version  : 10.0.13
OSDescription        : Ubuntu 24.04.5 LTS
RuntimeIdentifier    : ubuntu.24.04-x64
ProcessArchitecture  : X64
IsWindows            : False

同じソースが、.NET 8 と .NET 10 のランタイムで別々に動いています。.NET では、複数の版のランタイムを1台に並べて入れ、アプリごとに使う版が決まります。どの版で動くかは出力フォルダーの HelloNet.runtimeconfig.json に書かれていました。

{
  "runtimeOptions": {
    "tfm": "net8.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "8.0.0"
    }
  }
}

dotnet run での実行時間は、初回（ビルドを含む）が 6.9 秒、2回目が 2.8 秒でした。dotnet new list には46個のテンプレートがあり、Linux の SDK にも「Windows Forms App（winforms）」「WPF Application（wpf）」のテンプレートが含まれていました。ただし、そのビルドは「よくあるエラー」の節の NETSDK1100 のとおり、Linux ではそのままでは通りません。

publishの5つの形（サイズと起動時間の実測）

この節では、.NET のアプリを配るときの形（publish の種類）ごとに、出力の大きさと起動の速さがどれだけ違うかが分かります。

.NET Framework のアプリは「Windows に入っている Framework」を前提に .exe を配りますが、.NET は配り方を選べます。 上のプログラムを .NET 10 で5通りに publish し、出力の合計サイズと、30回起動した平均時間（3回測った範囲）を測りました。

R=ubuntu.24.04-x64
dotnet publish -c Release -o out/fdd
dotnet publish -c Release -r $R --self-contained -o out/sc
dotnet publish -c Release -r $R --self-contained -p:PublishSingleFile=true -o out/single
dotnet publish -c Release -r $R --self-contained -p:PublishSingleFile=true -p:PublishTrimmed=true -o out/trim
dotnet publish -c Release -r $R -p:PublishAot=true -o out/aot

NativeAOT の出力は、file で見ると普通の Linux の実行ファイル（ELF 64-bit）で、ldd で見た依存は libc と libm だけでした。.NET のランタイムが入っていないマシンでも、そのまま起動します。一方、トリミングした単一ファイルは、サイズは小さくなったのに起動は約3倍遅くなりました。 標準ライブラリはあらかじめ機械語に変換したコード（ReadyToRun）を含んでいますが、トリミングで書き換えるとそれが外れ、起動時の JIT が増えるためと考えられます。2コアの共有環境で測ったため、数値は目安です。

NativeAOT には、リフレクションを多用するライブラリが動かない場合があるなどの制約があります。公式ドキュメント「ネイティブ AOT の配置」で対応状況を確かめてから選びます。

.NET Frameworkのアプリは.NETで動くか（移行の判断表）

この節では、.NET Framework のアプリを .NET に移すかどうかの判断と、移せない技術、移す手順が分かります。

.NET Framework 向けにビルドした .exe・.dll は、.NET ではそのままは動きません。プロジェクトのターゲットを .NET に変えて、作り直します。 逆に、.NET の SDK で .NET Framework 向けにビルドすることはできますが、そのためには参照用のアセンブリ（Developer Pack か NuGet の Microsoft.NETFramework.ReferenceAssemblies）が要ります。Linux で <TargetFramework>net48</TargetFramework> を指定し、参照用アセンブリなしでビルドしたときのエラーです。

error MSB3644: The reference assemblies for .NETFramework,Version=v4.8 were not found. To resolve this, install the Developer Pack (SDK/Targeting Pack) for this framework version or retarget your application. You can download .NET Framework Developer Packs at https://aka.ms/msbuild/developerpacks

Windows で Visual Studio を使っていても、該当する版の「.NET Framework Developer Pack」が入っていないと同じ MSB3644 が出ます。

.NET に無い .NET Framework の技術

Microsoft Learn「.NET 6 以降で使用できない .NET Framework テクノロジ」の内容を、代わりの手段とあわせてまとめます。

ASP.NET Web Forms も .NET にはありません。ASP.NET Core（Razor Pages・MVC・Blazor）で作り直すことになります。

移すかどうかの判断表

移すときの順番

1. 1今のアプリを評価する使っている技術・NuGet パッケージ・外部 DLL の対応状況を洗い出す
2. 2リスクの小さいプロジェクトで試す公式は「リスクの低いプロジェクトで変更をパイロットする」ことを勧めている
3. 3ライブラリから先に移すnetstandard2.0 か複数ターゲットにして、両方から使える状態を作る
4. 4ツールで変換する公式の推奨は GitHub Copilot のアプリ モダン化エージェント。.NET Upgrade Assistant は非推奨になった
5. 5テストを通して最新化するappsettings.json・依存性の注入など、.NET の書き方へ寄せる

Microsoft Learn「.NET Framework から .NET への移植の概要」では、.NET Upgrade Assistant は「GitHub Copilot アプリ モダン化エージェントを優先して正式に非推奨となり、現在は積極的に開発されていません」と書かれています（2026年10月29日時点）。

よくあるエラー・つまずき（原文つき）

この節では、.NET Framework と .NET でよく出るエラーの文言と、その意味・直し方が分かります。

1つ目は、.NET 8 向けのアプリの設定ファイルを .NET 9 に書き換え、.NET 9 のランタイムが入っていない状態で起動して出しました。終了コードは 150 でした。

You must install or update .NET to run this application.

App: /dev/shm/t69/work/r9/HelloNet.dll
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '9.0.0' (x64)
.NET location: /usr/lib/dotnet/

The following frameworks were found:
  8.0.32 at [/usr/lib/dotnet/shared/Microsoft.NETCore.App]
  10.0.13 at [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

このとき環境変数 DOTNET_ROLL_FORWARD=Major を付けると、入っている上の版（10.0.13）で起動しました。ただし、上の版で必ず正しく動くとは限らないため、本番ではアプリを新しい版でビルドし直すのが確実です。

よくある質問

この節では、.NET Framework と .NET について、よく聞かれる質問への答えが分かります。

Q. .NET Framework はアンインストールしてよいですか？ A. Windows 10・11 の .NET Framework 4.8・4.8.1 は Windows に同梱され、Windows Update で更新される部品です（公式）。使っているアプリが起動しなくなるため、外さずに使い続けるのが基本です。3.5 は「Windows の機能」でオフにできますが、使っているアプリが起動しなくなります。

Q. .NET Framework は無料ですか？ A. 無料です。公式ページで、商用利用を含めて無料と書かれています。.NET も無料のオープンソースです。

Q. 複数の .NET Framework を同時に入れられますか？ A. 3.5 と 4.x は並べて入れられます。4.x どうしは上書き更新になり、同時に1つだけです。.NET（5 以降）は、8 と 10 のように複数の版を並べて入れられます。

Q. どのバージョンの .NET Framework を入れればよいですか？ A. 公式は最新の 4.8.1 を勧めています。4.x で作られたアプリは 4.8.1 で動き、3.5 で作られたアプリには 3.5 が要ります。

Q. .NET Core と .NET は別物ですか？ A. 同じ系統です。.NET Core 3.1 の次が .NET 5 で、名前から「Core」を外しました。今は .NET 10 が最新の LTS です。

Q. Mac や Linux で .NET Framework のアプリは動きますか？ A. .NET Framework は Windows 専用です。この記事では、Linux で .NET 8・10 のアプリを動かし、.NET Framework 4.8 向けのビルドが参照用アセンブリ不足で失敗することを確かめました。

Q. 「.NET Framework の初期化エラー」が出てアプリが起動しません。 A. アプリが求める版の .NET Framework が入っていないか、有効になっていないことが多いです。表示された版を確かめ、3.5 なら「Windows の機能」で有効にし、4.x なら Windows Update で 4.8.1 を入れます。

Q. .NET 8 のアプリは、2026年11月10日を過ぎると動かなくなりますか？ A. 動かなくなるわけではありません。セキュリティ修正が出なくなるため、公開しているサービスでは .NET 10 への更新が必要になります。

まとめ

• .NET Framework は Windows 専用のアプリ実行環境で、4.8.1（2022年8月）が最終版。新しい開発は .NET（現在の LTS は .NET 10）で行う。
• .NET Framework の版は、レジストリ NDP\v4\Full の Release の値で確かめる（533320 以上なら 4.8.1）。.NET の版は dotnet --list-sdks・--list-runtimes で確かめる。
• .NET 8・9 のサポートは2026年11月10日に終わる。.NET 10 は2028年11月14日まで。.NET Framework 4.6.2 は2027年1月12日、3.5 SP1 は2029年1月9日まで。
• 3.5 は「Windows の機能」で有効にする。Windows 11 26H1 以降は単体のインストーラーになった。
• Linux では、.NET 8・10 のアプリが動き、Windows だけの API（レジストリ）は null になった。publish の形で大きさは 97 KB〜76 MB、起動は NativeAOT が約3 ms と大きく変わった。

C# の書き方は、関連記事「C#クラスとプロパティの書き方｜get・set・initとrecordまで」、関連記事「C# null許容型の使い方｜??・?.演算子とis nullでnullチェック」で扱っています。.NET Framework から移すときに書き換えが多い非同期処理は関連記事「C# async/awaitの使い方｜Taskとデッドロック回避をコードで解説」、データの絞り込みは関連記事「C# LINQの使い方一覧｜Where・Select・GroupByを実行結果つきで」、エラーの扱いは関連記事「C#例外処理｜try-catch-finallyとthrowの違い・例外一覧」で扱っています。

参考・出典

確認日はいずれも 2026年10月29日です。

• Microsoft「.NET Framework とは」：https://dotnet.microsoft.com/ja-jp/learn/dotnet/what-is-dotnet-framework
• Microsoft「.NET とは」：https://dotnet.microsoft.com/ja-jp/learn/dotnet/what-is-dotnet
• Microsoft「.NET および .NET Core の公式サポート ポリシー」：https://dotnet.microsoft.com/ja-jp/platform/support/policy/dotnet-core
• Microsoft Learn「Microsoft .NET Framework（ライフサイクル）」：https://learn.microsoft.com/ja-jp/lifecycle/products/microsoft-net-framework
• Microsoft Learn「.NET Framework のバージョンと依存関係」：https://learn.microsoft.com/ja-jp/dotnet/framework/install/versions-and-dependencies
• Microsoft Learn「インストールされている .NET Framework バージョンを確認する」：https://learn.microsoft.com/ja-jp/dotnet/framework/install/how-to-determine-which-versions-are-installed
• Microsoft Learn「Windows への .NET Framework 3.5 のインストール」：https://learn.microsoft.com/ja-jp/dotnet/framework/install/dotnet-35-windows
• Microsoft Learn「Windows 11 への .NET Framework 3.5 のインストール」：https://learn.microsoft.com/ja-jp/dotnet/framework/install/dotnet-35-windows-11
• Microsoft Learn「Windows に .NET をインストールする」：https://learn.microsoft.com/ja-jp/dotnet/core/install/windows
• Microsoft Learn「SDK スタイル プロジェクトのターゲット フレームワーク」：https://learn.microsoft.com/ja-jp/dotnet/standard/frameworks
• Microsoft Learn「.NET Framework から .NET への移植の概要」：https://learn.microsoft.com/ja-jp/dotnet/core/porting/
• Microsoft Learn「.NET 6 以降で使用できない .NET Framework テクノロジ」：https://learn.microsoft.com/ja-jp/dotnet/core/porting/net-framework-tech-unavailable
• Microsoft Learn「.NET SDK と .NET CLI のテレメトリ」：https://learn.microsoft.com/ja-jp/dotnet/core/tools/telemetry
• Microsoft Learn「C# 言語のバージョン管理」：https://learn.microsoft.com/ja-jp/dotnet/csharp/language-reference/configure-language-version
• Microsoft .NET Blog「.NET STS releases supported for 24 months」：https://devblogs.microsoft.com/dotnet/dotnet-sts-releases-supported-for-24-months/
• Microsoft Learn「ネイティブ AOT の配置」：https://learn.microsoft.com/ja-jp/dotnet/core/deploying/native-aot/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。