Open棟梁Project - マイクロソフト系技術情報 Wiki
目次 †
概要 †
- 本ページでは、.NET Framework ランタイムや開発環境のバージョンアップに伴う.NETプログラムの環境移行、コンバージョン移行の作業範囲を扱います。
- プラットフォーム移行に伴う環境移行については、 Windows, IE移行、 64bit対応を参照下さい。
- また、下記の内、コンバージョン移行に該当する移行見積もりに関しては、プログラムの移行性評価作業 として、
１・２本のプログラムをサンプリングし、実際に移行 ～ テストした上で、移行作業全体の工数を見積もることをお薦めします。
サポートポリシーの変更 †
2014年8月7日(米国時間)発表があり、2016年1月12日以降サポート対象となるバージョンが大幅に減少するため注意
.NETの場合 †
.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 Framework2.0～3.5では、
一つのアプリケーション ドメイン
- 共通言語ランタイム（CLR）における、実行コードの管理単位。
- 従来のWindowsにおけるプロセスに相当する）
に、複数バージョンのランタイムをロードできないので（注１）、
アプリケーションはどれか１つのバージョンのランタイム上で動かす必要があります。
このため、例えば、.NET Framework1.1をターゲットとしたクラス ライブラリ（DLL）を
.NET Framework2.0のWindowsアプリケーション（EXE）から呼び出した場合、
当該DLLは、.NET Framework2.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 Framework2.0～3.5のいずれかのCLR(CLR2)と、
- .NET Framework 4のCLR(CLR4) の両方をロードできる様になる（参考1）
・・・ とのことですが、これは、COMアドインに限定されるようです（参考2）。
異なるランタイム（アプリケーション・ドメイン）でグローバル変数などの共有ができるとは考えにくいので、
すべてがCOMインターフェイス経由でブリッジされる場合に限定されるようです。
.NET Framework1.1 → 2.0～3.5 †
ランタイムのバージョンアップ †
既に説明しましたが、.NET Frameworkランタイムのバージョンアップは、環境移行に該当します。
- 高い後方互換性のため、基本的にVS2003で作成した、.NET Framework1.1をターゲットとしたアセンブリは、.NET Framework2.0～3.5で動作させることができます。
- このため.NET Framework2.0～3.5のみがインストールされている環境でもVS2003で作成したプログラムは動作します。
- しかし、一部後方互換を犠牲にしている所があるため、テストなどは必要になります。
開発環境のバージョンアップ †
.NET Frameworkのバージョンアップに伴い一部犠牲となった後方互換の問題を完全に解決するには、
- VS2003プロジェクトを VS2005、2008に付属の変換ツール で変換して、
- .NET Framework2.0～3.5をターゲットとしたアセンブリとしてビルドする
必要があります。
こちらの作業は、手修正無しのコンバージョン移行に該当し、変換後、必要に応じて
- 「後方互換の打ち切り（予告）によるエラー（ワーニング）落とし」（注２）
- 「後方互換の打ち切りによるプログラム修正（APIの差替）」
などの修正を施します 。
この変換ツールは、ソリューション / プロジェクト ファイルやconfigファイル、一部のソースコードを変換しますが、
VS2005、2008（.NET Framework2.0～3.5）でサポートされた新機能を使用するようには変換されません。
このため、例えば、以下の新機能を使用する場合、コードを手修正する必要があります。
- レイアウト記述ファイルの分離
Windows（Web） フォーム デザイナで生成されたコードは、VS2002、2003は、Windows（Web） フォームの分離コード ファイルと同一のファイル内の、
Regionプリプロセッサ ディレクティブ：「Windows（Web） フォーム デザイナで生成されたコード」内に記述されるが、
VS2005以降では、Windows（Web） フォーム デザイナで生成されたコードは、さらに、レイアウト記述ファイル（.Designer.vb（.cs））に分離される。
- .etc
.NET Framework Version 2.0、3.0、3.5の新機能を参照。
- 注２： 後方互換の打ち切り予告の対象クラスには、MSDNクラスライブラリ リファレンス中に
「メモ ： このクラスは、互換性のために残されています。」という記述が見られる。
製品サポート状況の確認 †
3rdパーティ製品が、.NET Frameworkの最新バージョンをサポートしていない場合があるので注意が必要です。
また、.NET Framework ランタイムや開発環境のバージョンアップに伴い、 使用する3rdパーティ製ライブラリの当該環境上でのサポートが無くなる場合、
代替ライブラリのI/F変更発生に起因する修正範囲拡大の可能性があります ので、その場合の移行作業は手修正有りのコンバージョン移行に近づきます。
.NET Framework2.0 → 3.0、3.5 †
- .NET Framework3.0、3.5は2.0上で動作する追加クラス群であるため、
.NET Framework2.0は、3.0、3.5のランタイム上で動作します。
- その他、基本的な考え方は、上記の「.NET Framework1.1 → 2.0～3.5」と同じです。
.NET Framework1.1、2.0、3.0、3.5 → 4、4.5(4.5.1, 4.5.2) †
- .NET Frameworkランタイムのバージョンアップになるので、環境移行に該当します。
- 従って、基本的な考え方は、上記の「.NET Framework1.1 → 2.0～3.5」と同じです。
.NET Framework4 → 4.5( → 4.5.1, → 4.5.2) †
- .NET Frameworkランタイムのバージョンアップになるので、環境移行に該当します。
- .NET Framework4 と.NET Framework4.5(4.5.1, 4.5.2) は共存できないようですが、
高い後方互換を持つため殆ど修正無しで実行可能とのことです。
- 従って、基本的な考え方は、上記の「.NET Framework1.1 → 2.0～3.5」と同じです。
ASP.NETの場合 †
ASP.NETの場合は、ASP.NET1.1からASP.NET2.0への移行になります。
上記の「.NET Framework1.1 → 2.0～3.5」より少々複雑になります。
ランタイムのバージョンアップ †
プロジェクト ファイルやconfigファイルの変更などが必要になるため、
新しい開発環境に付属の変換ツールを使用して変換します（環境移行ではない）。
開発環境のバージョンアップ †
上記の「.NET Framework1.1 → 2.0～3.5」と同様に、
VS2003プロジェクトをVS2005、2008に付属の変換ツールで変換して、
ASP.NET2.0をターゲットとしたWebアプリケーションとして再構成する必要があります。
こちらの作業は、手修正無しのコンバージョン移行に該当します。
また、特に大きな変更として、ASP.NET2.0では、デフォルトのHTMLレンダリングが、
HTML4.01（ASP.NET1.1） → XHTML（ASP.NET2.0）と変更されます。
上記の変換ツールを使用した場合、configファイルのxhtmlConformanceタグの
mode属性にLegacyが設定され、HTML4.01でレンダリングされます。
レンダリングをHTML4.01からXHTMLに変更する場合は、
- aspxファイル中に記述されたHTMLや、
- <% Response.Write( string ) %>、 <% = string %> などの
直接出力に問題があれば修正が必要になります
（Web コントロールを使用していれば、自動的に指定のDTDに対応したHTMLが出力されます）。
この部分の修正量が多くなるようであれば、移行作業は手修正有りのコンバージョン移行に近づきます。
また同様に、この変換ツールは、ソリューション / プロジェクト ファイルやconfigファイル、一部のソースコードを変換しますが、
VS2005、2008（ASP.NET2.0）でサポートされた新機能を使用するようには変換されません。
このため、例えば、以下の新機能を使用する場合、コードを手修正する必要があります。
を参照。
製品サポート状況の確認 †
上記の「.NET Framework1.1 → 2.0～3.5」と同様に、製品サポート状況の確認が必要です。
また同様に、.NET Framework ランタイムや開発環境のバージョンアップに伴い、
使用する3rdパーティ製ライブラリの当該環境上でのサポートが無くなる場合、
代替ライブラリのI/O、I/F変更発生に起因する修正範囲拡大の可能性がありますので、
その場合の移行作業は手修正有りのコンバージョン移行に近づきます。
確認のポイントとしては、
- インターフェイス変更、動作変更が無いか？
- 上記のweb.configファイルのxhtmlConformanceタグのmode属性に
Legacyを設定した場合の、HTML4.01でのレンダリングに対応しているか？
などが考えられます。
関連リンク †
内部リンク †
.NET Framework 移行センター †
http://www.microsoft.com/japan/net/migration/
MSDN †
テクニカルドキュメント > .NET 開発 †
- 開発ツールと言語ドキュメント > Visual Studio 2005 Visual Studio > ドキュメント
- Visual Web Developer ドキュメント >Web ページ > Web ページ デザイナ > 詳細説明
その他 †
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
