マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

目次

概要

  • 本ページでは、.NET Framework ランタイムや開発環境のバージョンアップに伴う
    .NETプログラムの環境移行、コンバージョン移行の作業範囲を扱います。
  • プラットフォーム移行に伴う環境移行については、 Windows, IE移行64bit対応を参照下さい。
  • また、下記の内、コンバージョン移行に該当する移行見積もりに関しては、プログラムの移行性評価作業 として、
    1・2本のプログラムをサンプリングし、実際に移行 ~ テストした上で、移行作業全体の工数を見積もることをお薦めします。

.NET Framework のバージョン

新機能

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

同居の可否

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

.NET Framework バージョンとコンポーネント

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

.NET Framework の サポート ライフサイクル ポリシー

基本的に親のオペレーティング システムの
サポート ライフサイクル ポリシーに従うようになっている。

サポートポリシーの変更

2016年1月12日以降サポート対象となるバージョンが大幅に減少

.NETの場合

.NETの場合、

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

に該当します。

  • .NET Frameworkは高い後方互換性を維持しており、
    旧バージョンのVisual Studio(以下、VSと略す)で作成した、.NET Frameworkのアセンブリも、
    新バージョンの.NET Frameworkで動作させることができます(注0)。
  • しかし、新バージョンの.NET Frameworkは、セキュリティおよび機能改善のために、
    一部、旧バージョンの.NET Frameworkの後方互換を犠牲にしている所があり、
    これを解決するために、複数のバージョンの.NET Frameworkの共存が可能になっています。
    • このため、 実行環境中に旧バージョンの.NET Frameworkがインストールされている場合、
      旧.NET Frameworkバージョンのアセンブリは、旧バージョンの.NET Frameworkで動作します。
    • 実行環境中に旧バージョンの.NET Frameworkがインストールされていない場合は、
      高い後方互換性を維持した、新バージョンの.NET Frameworkで動作します)。
  • また、.NET Framework 2.0 ~ 3.5では、
    一つのアプリケーション ドメイン
    • 共通言語ランタイム(CLR)における、実行コードの管理単位。
    • 従来のWindowsにおけるプロセスに相当する)

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

  • 注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 のわずかな変更やプログラミング技法の変化によって損なわれている可能性があります。

  • 注1: .NET Framework 4からは、一つのアプリケーション ドメインに、
    • .NET Framework 2.0 ~ 3.5のいずれかのCLR(CLR2)と、
    • .NET Framework 4のCLR(CLR4) の両方をロードできる様になる(参考1

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

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

.NET Framework 1.1 → 2.0、3.0、3.5

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

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

  • 高い後方互換性のため、基本的にVS 2003で作成した、.NET Framework1.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をターゲットとしたアセンブリとしてビルドする

必要があります。

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

  • 「後方互換の打ち切り(予告)によるエラー(ワーニング)落とし」(注2)
  • 「後方互換の打ち切りによるプログラム修正(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.03.03.5の新機能を参照。
  • 注2: 後方互換の打ち切り予告の対象クラスには、MSDNクラスライブラリ リファレンス中に
    「メモ : このクラスは、互換性のために残されています。」という記述が見られる。

製品サポート状況の確認

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

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

.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 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ランタイムのバージョンアップになるので、環境移行に該当します。
  • .NET Framework 4 と.NET Framework 4.5 ( 4.5.1, 4.5.2 ) は、置き換えのインプレース更新。
    従って、共存できないようですが、高い後方互換を持つため殆ど修正無しで実行可能とのことです(逆は不可)。
  • 従って、基本的な考え方は、上記の「.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

  • 4.5の置き換えのインプレース更新。
  • インストール済みの.NET Framework x Developer PackのTargetframeworkに変更可能
  • 置き換えであることを除き、基本的には上記の「.NET Framework 1.1 → 2.0 ~ 3.5」と同じ。

.NET Framework 4.6 → 4.6.1 → 4.6.2

  • (引き続き、4.5以降の)置き換えのインプレース更新。
  • インストール済みの.NET Framework x Developer PackのTargetframeworkに変更可能
  • 置き換えであることを除き、基本的には上記の「.NET Framework 1.1 → 2.0 ~ 3.5」と同じ。

.NET Framework 4.6 → 4.7

  • (引き続き、4.5以降の)置き換えのインプレース更新。
  • インストール済みの.NET Framework x Developer PackのTargetframeworkに変更可能
  • 置き換えであることを除き、基本的には上記の「.NET Framework 1.1 → 2.0 ~ 3.5」と同じ。

.NET Standardへの移行

近々、評価予定。

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 マスタ ページ
    http://msdn.microsoft.com/ja-jp/library/ms379585.aspx
    • Web サイト全体で一貫した外観を維持するための新しい手法を提供する。
    • マスタ ページを更新するだけで、複数ページに及ぶサイトの外観を簡単に変更できる。

を参照。

ASP.NET 4

  • VS 付属の変換ツール で変換する。
  • .NET Framework 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 FormsASP.NET MVCへの移行

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

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

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

関連リンク

.NET Framework 移行センター

http://www.microsoft.com/japan/net/migration/

アプリケーションの移行の必要性を考える

アプリケーションの移行にあたって

移行に必要な技術情報

MSDN

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

  • .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ソリューション > .NET Frameworkマイグレーション
    http://www.unisys.co.jp/dotnet/dotnetmigration.html
    • .NET Framework 1.1/3.5 移行ホワイトペーパー
    • .NET to .NET マイグレーション ~ 移行計画立案と実践 ~

Tags: :移行, :.NET開発


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2017-12-11 (月) 20:55:15 (341d)