Skip to content

MS_DotNetVersionUpgrade

Jump to bottom
nishi_74322014 edited this page Aug 31, 2026 · 2 revisions

.NETバージョンアップ

概要

  • 本ページでは、.NET Framework ランタイムや開発環境のバージョンアップ
    に伴う .NET プログラムの環境移行、コンバージョン移行の作業範囲を扱います。

  • プラットフォーム移行に伴う環境移行については、
    Windows, IE移行、64bit対応を参照下さい。

  • また、下記の内、コンバージョン移行に該当する移行見積もりに関しては、
    プログラムの移行性評価作業として、
    １・２本のプログラムをサンプリングし、実際に移行 〜 テストした上で、
    移行作業全体の工数を見積もることをお薦めします。

補足（環境移行とコンバージョン移行）: 本ページを通じて使われる
この 2 語が判断の軸になっている。

用語 意味 作業
環境移行 バイナリはそのまま、動かす環境だけ変える 動作確認・テストが中心
コンバージョン移行（手修正なし） ツールで変換して再ビルドする 変換 ＋ 警告潰し
コンバージョン移行（手修正あり） コードの書き換えが要る 実質的な改修

「どれに該当するか」で工数が桁違いになるため、
冒頭の「1〜2 本をサンプリングして実測してから見積もる」という助言は
極めて実践的である。

バージョン

.NET Framework

新機能

以下のページで .NET Framework の各バージョンの主な新機能や
強化された機能の概要が説明されている。

同居の可否

  • インプレース更新という用語を使用しているようなので、これで検索すると良い。
  • インプレース更新では、更新後、下位のバージョンは削除される（同居不可）。
  • 基本的に、
    • 1.1、2.0、3.0、3.5 までは同居が可能で、
    • 4 以降が、インプレース更新で同居不可になっている。

補足（この違いが .NET Core との対比の起点）: 「4 以降はインプレース更新で
同居不可」という制約が、後の .NET Core の
設計思想（アプリごとにランタイムを選ぶ）を生んだ。

【.NET Framework 4.x】
  マシンに 1 つだけ。更新すると全アプリに影響する
  → 「あるアプリのために上げられない」という膠着が起きる

【.NET Core / .NET】
  複数バージョンが並存。アプリが使う版を指定できる
  → SCD にすればアプリに同梱もできる

詳細は .NET Coreのデプロイ を参照。

.NET Framework バージョン間の互換性

.NET Framework のバージョンとサポート

サポート ポリシー

補足（現況）: 現在サポートされている .NET Framework は
4.6.2 / 4.7.2 / 4.8 / 4.8.1 のみで、それ以前は終了している。
いずれも「親の OS のライフサイクルに従う」ため、
Windows がサポートされている限り修正が提供される
（終了日が明示されない）。

.NET Core

各バージョン

  • 概要

    • .NET Core 2.0 以降、.NET Framework に近い感じの開発が可能になっている。
    • .NET 5 名前から "Core" が外れ、実質、.NET のメインストリームへ。

  • バージョン

バージョン リリース 区分
.NET Core 1.0 2016-06-27
.NET Core 1.1 2017-03-07
.NET Core 2.0 2017-08-14
.NET Core 2.1 2018-05-30 LTS
.NET Core 2.2 2018-12-04
.NET Core 3.0 2019-09-23
.NET Core 3.1 2019-12 LTS
.NET 5 2020-11
.NET 6 2021-11 LTS
.NET 7 2022-11
.NET 8 2023-11 LTS
.NET 9 2024-11
.NET 10 2025-11 LTS

※ 移行についてはコチラ

新機能

以下のページで .NET Core の各バージョンの主な新機能や
強化された機能の概要が説明されている。

同居の可否

移行メモ（正誤）: 「恐らく不可能」は誤りで、
.NET Core / .NET は複数バージョンの同居が可能である。

C:\Program Files\dotnet\shared\Microsoft.NETCore.App\
  6.0.36\
  8.0.11\
  10.0.0\      ← 並存する

アプリ側は runtimeconfig.json で必要な版を指定し、
ロールフォワードの規則に従って実際に使う版が選ばれる。
SDK についても global.json でプロジェクトごとに固定できる。

つまり、原文が .NET Framework の
インプレース更新の印象から推測した記述と解されるが、
.NET Core 系はこの制約を解消することを目的の一つとしていた。
したがって「代替案」として挙げられているコンテナや SCD は、
同居のためではなく、より強い固定（環境ごと固める）
のための手段と理解するのが正しい。

.NET Core バージョン間の互換性

.NET Framework の時には無かった、破壊的変更が在り得る。

補足（この対比が重要）: .NET Framework が
後方互換性を最優先（そのために古い挙動を残し続ける）だったのに対し、
.NET Core 系は必要なら壊す方針に転換した。

.NET Framework .NET（Core 系）
方針 互換性最優先 進化のため必要なら破壊的変更
更新 インプレース（全アプリに影響） アプリごとに選べる
帰結 古い挙動が残り続ける 移行作業が定期的に発生する

「アプリごとに版を選べる」からこそ破壊的変更が許容できる、
という設計上の一貫性がある。
逆に言えば、年 1 回の移行作業を運用に織り込む必要がある。

.NET Core のバージョンとサポート

以下で確認できる。

サポート ポリシー

  • "Current" と "LTS（長期サポート）" がある。

    • Current リリース

      • フィードバックに基づいて将来変更され得る新機能が含まれている。
      • .NET Core のリリースに対応してアップグレードする必要がある。

    • LTS（長期サポート）リリース
      最初のリリース後、3 年間、若しくは、次 LTS のリリース後、1 年間サポートされる。

      • 長期サポート用に設計されている。
      • 安定化された機能とコンポーネントが含まれている。
      • 更新する予定の無いアプリケーションをホストするのに適している。

    • 慣例

      • .NET 5.0 以前
        X.偶数(e.g.:2.0, 2.2, 3.0) が Current、X.奇数(e.g.:2.1, 3.1) が LTS。
      • .NET 5.0 以降
        奇数.0 系(e.g.:5.0) が Current、偶数.0 系(e.g.:6.0) が LTS。

    • 共通項
      どちらのリリースも、セキュリティ、信頼性、または新しい OS バージョンの
      サポート追加 / 享受のため、最新のパッチを最新の状態に保つ必要がある。

補足（最新化）: 「Current」は現在
**STS（Standard Term Support、標準期間サポート）**という名称に変わっている。

区分 期間
LTS（偶数版） 3 年
STS（奇数版） 18 か月

どちらも「次のリリース後 6 か月」ではなく固定期間になった。
原文の「次 LTS のリリース後 1 年間」は古い規定である。

参考

.NET Framework の場合

概要

.NET の場合、

  • .NET Framework ランタイムのバージョンアップは、環境移行
  • 開発環境のバージョンアップは、コンバージョン移行

に該当します。

  • .NET Framework は高い後方互換性を維持しており、
    旧バージョンの Visual Studio（以下、VS と略す）で作成した、
    .NET Framework のアセンブリも、
    新バージョンの .NET Framework で動作させることができます（注０）。

  • しかし、新バージョンの .NET Framework は、セキュリティおよび機能改善のために、
    一部、旧バージョンの .NET Framework の後方互換を犠牲にしている所があり、
    これを解決するために、複数のバージョンの .NET Framework の共存が可能になっています。

    • このため、実行環境中に旧バージョンの .NET Framework がインストールされている場合、
      旧 .NET Framework バージョンのアセンブリは、旧バージョンの .NET Framework で動作します。
    • 実行環境中に旧バージョンの .NET Framework がインストールされていない場合は、
      高い後方互換性を維持した、新バージョンの .NET Framework で動作します。

  • また、.NET Framework 2.0 〜 3.5 では、
    一つのアプリケーション ドメイン

    • 共通言語ランタイム（CLR）における、実行コードの管理単位。
    • 従来の Windows におけるプロセスに相当する）

    に、複数バージョンのランタイムをロードできないので（注１）、
    アプリケーションはどれか１つのバージョンのランタイム上で動かす必要があります。
    このため、例えば、.NET Framework 1.1 をターゲットとしたクラス ライブラリ（DLL）を
    .NET Framework 2.0 の Windows アプリケーション（EXE）から呼び出した場合、
    当該 DLL は、.NET Framework 2.0 上で動作します。
    このため、この点については環境移行として考えることができます。

注０：.NET Framework のバージョンの互換性

下位互換とは、プラットフォームの特定のバージョンで開発されたアプリケーションが、
そのプラットフォームの新しいバージョンでも実行できることを意味します。

  • .NET Framework では、下位互換性が最大限に高められています。

  • .NET Framework のあるバージョンで記述されたソース コードは、

    • .NET Framework の新しいバージョンでコンパイルでき、
    • .NET Framework のあるバージョンで実行されるバイナリは、
      新しいバージョンの .NET Framework でも同じように動作します。

  • .NET Framework 4.5 は、.NET Framework の Version 1.1、2.0、3.0、3.5、
    および 4 でビルドされたアプリケーションと下位互換性があります。

つまり、旧バージョンの .NET Framework でビルドしたアプリケーションとコンポーネントは、
.NET Framework 4.5 で動作します。
ただし、現実的には、この互換性は、.NET Framework のわずかな変更や
プログラミング技法の変化によって損なわれている可能性があります。

注１：.NET Framework 4 からは、一つのアプリケーション ドメインに、

.NET Framework 4 以降では、同居ができなくなりましたが、
それ以前とは同居が可能で、一つのアプリケーション ドメインに、

  • .NET Framework 2.0 〜 3.5 のいずれかの CLR(CLR2) と、
  • .NET Framework 4 の CLR(CLR4) の両方をロードできる様になる
    （参考1）

・・・ とのことですが、これは、COM アドインに限定されるようです
（参考2）。

異なるランタイム（アプリケーション・ドメイン）でグローバル変数などの共有ができるとは
考えにくいので、すべてが COM インターフェイス経由でブリッジされる場合に
限定されるようです。

補足（原文の推論は正しい）: これは In-Process Side-by-Side (SxS) という
機能で、原文の推測どおりCOM 経由の相互運用に限定される。

想定されていたのは「Office のアドイン」のような状況で、
1 つのホスト プロセスに、異なる .NET で作られたアドインが
複数読み込まれる場合である。
マネージド コードを直接呼び合うことはできず、
COM の境界を越える形でのみ共存できる。
「グローバル変数を共有できるとは考えにくい」という直感は的確。

.NET Framework 1.1 → 2.0、3.0、3.5

ランタイムのバージョンアップ

既に説明しましたが、.NET Framework ランタイムのバージョンアップは、環境移行に該当します。

  • 高い後方互換性のため、基本的に VS 2003 で作成した、
    .NET Framework 1.1 をターゲットとしたアセンブリは、
    .NET Framework 2.0 〜 3.5 で動作させることができます。
  • このため .NET Framework 2.0 〜 3.5 のみがインストールされている環境でも
    VS 2003 で作成したプログラムは動作します。
  • しかし、一部後方互換を犠牲にしている所があるため、テストなどは必要になります。

開発環境のバージョンアップ

.NET Framework のバージョンアップに伴い一部犠牲となった後方互換の問題を完全に解決するには、

  • VS 2003 プロジェクトを VS 2005、2008 に付属の変換ツールで変換して、
  • .NET Framework 2.0 〜 3.5 をターゲットとしたアセンブリとしてビルドする

必要があります。

こちらの作業は、手修正無しのコンバージョン移行に該当し、変換後、必要に応じて

  • 「後方互換の打ち切り（予告）によるエラー（ワーニング）落とし」（注２）
  • 「後方互換の打ち切りによるプログラム修正（API の差替）」

などの修正を施します。

この変換ツールは、ソリューション / プロジェクト ファイルや config ファイル、
一部のソースコードを変換しますが、
VS 2005、2008（.NET Framework 2.0 〜 3.5）でサポートされた新機能を
使用するようには変換されません。
このため、例えば、以下の新機能を使用する場合、コードを手修正する必要があります。

  • レイアウト記述ファイルの分離
    Windows（Web） フォーム デザイナで生成されたコードは、VS 2002、2003 は、
    Windows（Web） フォームの分離コード ファイルと同一のファイル内の、
    Region プリプロセッサ ディレクティブ：「Windows（Web） フォーム デザイナで生成されたコード」内に
    記述されるが、
    VS 2005 以降では、Windows（Web） フォーム デザイナで生成されたコードは、
    さらに、レイアウト記述ファイル（.Designer.vb（.cs））に分離される。

  • .etc
    .NET Framework Version 2.0、3.0、3.5 の新機能を参照。

製品サポート状況の確認

3rd パーティ製品が、.NET Framework の最新バージョンをサポートしていない場合があるので
注意が必要です。

また、.NET Framework ランタイムや開発環境のバージョンアップに伴い、
使用する 3rd パーティ製ライブラリの当該環境上でのサポートが無くなる場合、
代替ライブラリの I/F 変更発生に起因する修正範囲拡大の可能性がありますので、
その場合の移行作業は手修正有りのコンバージョン移行に近づきます。

補足（この指摘が移行工数の最大の変動要因）: 本ページで繰り返し出てくる
**「3rd パーティ製品のサポート状況」**が、実際の見積もりを左右する。

ランタイムの互換性  … Microsoft が高く保っている（比較的安全）
3rd パーティ製品     … 提供元次第（ここが読めない）

特に、提供元が既に無い / 保守が切れているコンポーネントがあると、

  • 代替品を探す → I/F が違う → 呼び出し側の改修、
  • 代替が無い → 自作 or 機能削減、

となり、一気に「手修正ありのコンバージョン移行」に転落する。
.NET 8への移行 が
「NuGet パッケージ（OSS）が更新されているか確認」と述べているのも同じ論点で、
時代が変わっても構図は同じである。

注２： 後方互換の打ち切り予告の対象

MSDN クラスライブラリ リファレンス中に
「メモ ： このクラスは、互換性のために残されています。」という記述が見られる。

補足: 現在の Microsoft Learn では [Obsolete] 属性と
**「この API は現在使われていません」**という表記で示される。
ビルド時に警告（CS0618 / SYSLIB****）として出るため、
警告を潰す作業がそのまま移行作業になる。

.NET Framework 2.0 → 3.0、3.5

  • .NET Framework 3.0、3.5 は 2.0 上で動作する追加クラス群であるため、
    .NET Framework 2.0 は、3.0、3.5 のランタイム上で動作します。

  • その他、基本的な考え方は、上記の「[.NET Framework 1.1 → 2.0 〜 3.5](#net-framework-11--2030 35)」と同じです。

.NET Framework 2.0、3.0、3.5 → 4

  • .NET Framework ランタイムのバージョンアップになるので、環境移行に該当します。

  • 従って、基本的な考え方は、上記の「.NET Framework 1.1 → 2.0 〜 3.5」と同じです。

.NET Framework 4 以降

.NET Framework 4 → 4.5

置き換えのインプレース更新。

  • .NET Framework 4 以降はインプレース更新
    従って、共存できないようですが、高い後方互換を持つため
    殆ど修正無しで実行可能とのことです（逆は不可）。

  • 従って、基本的な考え方は、上記の「.NET Framework 1.1 → 2.0 〜 3.5」と同じです。

.NET Framework 4.5 → 4.5.1 → 4.5.2

(2)、(3) は後方互換性が高いので殆ど修正作業が発生しないと思います。
ただ、テストがどれだけ必要か？見積もるか？はポイントになると思います。

.NET Framework 4.5 → 4.6

  • 置き換えのインプレース更新。
  • 同上

.NET Framework 4.6 → 4.6.1 → 4.6.2

  • net46 → net461 → net462
  • 同上

.NET Framework 4.6 → 4.7

.NET Framework 4.7 → 4.7.1 → 4.7.2

  • net47 → net471 → net472
  • 同上

移行メモ（誤記）: 原文の見出しは
「.NET Framework 4.7 → 4.7.2 → 4.7.2」となっていたが、
本文が net47 → net471 → net472 であることから
4.7 → 4.7.1 → 4.7.2 の誤記と判断し修正した。

.NET Framework 4.7 → 4.8

.NET Framework 4.8 → 4.8.x

  • 4.8.1：2022 年 8 月 9 日、Windows 10 ver.20H2 以降を対象に ARM64 のネイティブサポートを追加
  • 4.8.2：...

.NET 5 以降

.NET 5 ≒ .NET Core 系への移行

ASP.NET の場合

ランタイムのバージョンアップ

プロジェクト ファイルや config ファイルの変更などが必要になるため、
新しい開発環境に付属の変換ツールを使用して変換します（環境移行ではない）。

開発環境のバージョンアップ

ASP.NET 2.0

ASP.NET の場合は、ASP.NET 1.1 から ASP.NET 2.0 への移行になります。
上記の「.NET Framework 1.1 → 2.0 〜 3.5」より少々複雑になります。

上記の「.NET Framework 1.1 → 2.0 〜 3.5」と同様に、
VS 2003 プロジェクトを VS 2005、2008 に付属の変換ツールで変換して、
ASP.NET 2.0 をターゲットとした Web アプリケーションとして再構成する必要があります。
こちらの作業は、手修正無しのコンバージョン移行に該当します。

また、特に大きな変更として、ASP.NET 2.0 では、デフォルトの HTML レンダリングが、
HTML 4.01（ASP.NET 1.1） → XHTML（ASP.NET 2.0）と変更されます。
上記の変換ツールを使用した場合、config ファイルの xhtmlConformance タグの
mode 属性に Legacy が設定され、HTML4.01 でレンダリングされます。

レンダリングを HTML4.01 から XHTML に変更する場合は、

  • aspx ファイル中に記述された HTML や、
  • <% Response.Write( string ) %>、<% = string %> などの

直接出力に問題があれば修正が必要になります
（Web コントロールを使用していれば、自動的に指定の DTD に対応した HTML が出力されます）。
この部分の修正量が多くなるようであれば、移行作業は手修正有りのコンバージョン移行に近づきます。

また同様に、この変換ツールは、
ソリューション / プロジェクト ファイルや config ファイル、一部のソースコードを変換しますが、
VS 2005、2008（ASP.NET 2.0）でサポートされた新機能を使用するようには変換されません。

このため、例えば、以下の新機能を使用する場合、コードを手修正する必要があります。

  • ASP.NET 2.0 マスタ ページ

    • Web サイト全体で一貫した外観を維持するための新しい手法を提供する。
    • マスタ ページを更新するだけで、複数ページに及ぶサイトの外観を簡単に変更できる。

  • .etc

    • ASP.NET 2.0 の新機能
    • .NET Framework Version 2.0、3.0、3.5 の新機能の内、ASP.NET に関する機能

を参照。

ASP.NET 4

製品サポート状況の確認

3rd パーティ

上記の「.NET Framework 1.1 → 2.0 〜 3.5」と同様に、製品サポート状況の確認が必要です。
また同様に、.NET Framework ランタイムや開発環境のバージョンアップに伴い、
使用する 3rd パーティ製ライブラリの当該環境上でのサポートが無くなる場合、
代替ライブラリの I/O、I/F 変更発生に起因する修正範囲拡大の可能性がありますので、
その場合の移行作業は手修正有りのコンバージョン移行に近づきます。

確認のポイントとしては、

  • インターフェイス変更、動作変更が無いか？
  • 上記の Web.config ファイルの xhtmlConformance タグの mode 属性に
    Legacy を設定した場合の、HTML 4.01 でのレンダリングに対応しているか？

などが考えられます。

OSS（ASP.NET AJAX : ASP.NET AJAX Control Toolkit など）

OSS のメンテ状況や、以下の様な移行情報の有無を確認しておく。

ASP.NET Web Forms → ASP.NET MVC への移行

アーキテクチャが別物なので再構築が必要。

ASP.NET MVC 5 → ASP.NET Core MVC への移行

ASP.NET MVC 5 → ASP.NET Core MVC も、
同じ MVC アーキテクチャだが ≒ 別物 ≒ 再構築。

.NET Core 系

.NET Standardへの移行

.NET Coreへの移行

ASP.NET Coreへの移行

Windows Desktop Packsへの移行

.NET Coreバージョンアップ

関連リンク

.NET Framework 移行センター

（現在は Microsoft Learn の移行ガイドに統合）

MSDN > テクニカルドキュメント > .NET 開発

.NET Framework

  • .NET Framework の互換性と移行に関する情報
    http://msdn.microsoft.com/ja-jp/library/cc825635.aspx

    • .NET Framework 1.0 から 1.1 への変更情報
    • .NET Framework 2.0 へのマイグレーション情報
    • Visual Studio に関する互換性情報
    • Windows Vista に関する互換性情報
    • 開発ツール サポート情報

  • .NET Framework 4

  • .NET Framework 4.5

    • .NET Framework 4.5 移行ガイド
      • .NET Framework 4.5 の新機能
      • .NET Framework 4.5 のアプリケーションの互換性
      • .NET Framework 1.1 からの移行
      • .NET Framework のバージョンの互換性
      • .NET Framework のバージョンおよび依存関係
      • .NET Framework の互換性のために残されている機能

ASP.NET

  • Web アプリケーション (ASP.NET) > ASP.NET 2.0
    • 概要:Microsoft ASP.NET 2.0 に向けての Web アプリケーションの再構築
    • 移行:
      • ASP.NET 1.x から ASP.NET 2.0 への移行
      • .NET Pet Shop 4: ASP.NET 1.1 アプリケーションを 2.0 に移行する
      • VS.NET 2002/2003 から VS2005 への Web プロジェクト変換ステップバイステップ ガイド
      • Web プロジェクトの一般的な変換問題およびソリューション

.NET Framework - Wikipedia

https://ja.wikipedia.org/wiki/.NET_Framework

.NET Compatibility Diagnostic Tools

.NET Framework Application Compatibility

Tags: 移行, .NET開発

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally