Microsoft .NET Framework 1.1 と 2.0 の互換性
開発と展開のベスト プラクティス
Microsoft Corporation
2006 年 5 月
内容
はじめに
概要
破壊的変更の定義
アプリケーションの読み込みメカニズムと考えられる問題
.NET Framework 2.0 に対する .NET Framework 1.1 を使用して開発されたアプリケーションのテスト
考えられる互換性の問題を軽減するための戦術
潜在的なホットスポット
行動への呼び掛け
付録と背景
はじめに
Microsoft .NET Framework 2.0 は、Web および Microsoft Windows クライアント アプリケーションに最適なランタイム環境を提供するために、Microsoft .NET Framework 1.0 と 1.1 の成功に基づいています。 .NET Framework 1.1 アプリケーションの Microsoft の互換性の目標は、ここに記載されている一連の変更を除き、.NET Framework 2.0 でスムーズに動作する必要があるということです。
この記事では、アプリケーションの互換性シナリオについて説明し、開発者が互換性の問題を処理するためのベスト プラクティスに関する推奨事項を示します。
概要
- 既知の破壊的変更の完全な一覧については、 こちらを参照してください。
- Microsoft では、.NET Framework 2.0 に対して.NET Framework 1.1 アプリケーションをテストすることをお勧めします。 これを行う手順については、「 互換性テスト シナリオ」を参照してください。
- .NET Framework 1.1 でビルドされたスタンドアロンの Microsoft Windows クライアントまたは Web アプリケーションは、.NET Framework 2.0 がコンピューターにインストールされている場合でも、そのフレームワークに対して自動的に実行されます。
- Microsoft Office やインターネット エクスプローラーなどのネイティブ アプリケーションへのマネージド アドインは、コンピューターにインストールされている.NET Frameworkの最新バージョンに対して自動的に実行されます。 開発者と IT マネージャーは、そのバージョンのフレームワークをデプロイする前に、.NET Framework 2.0 に対してアドインをテストする必要があります。
- アプリケーションの互換性に関する情報について説明し、公開するには、次の MSDN フォーラムを使用します: .NET Framework展開
破壊的変更の定義
破壊的変更は、特定のアプリケーションと開発シナリオの動作が異なる.NET Framework (ランタイムの破壊的変更) または Visual Studio (デザイン/コンパイル/プロジェクトアップグレード) の変更です。 これらは必ずしもアプリケーションを壊していることがわかった変更ではありません。むしろ、これらは、設計レビューとテスト中に検出された動作の変化であり、アプリケーションに影響を与える可能性があります。 実際、すべてのアプリケーション互換性テストで、アプリケーションに影響することがわかったのは、そのうちの 10 個未満です。
ランタイムの変更は、2 つのカテゴリに分類できます。1 つ目 (まれ) は、関数のシグネチャが変更されたか、関数が削除された API 破壊的変更です。 ほとんどの場合、これらの変更はセキュリティ上の懸念から行われました。 これらのうち、.NET Framework 2.0 全体で 5 未満です。
2 つ目の一般的な破壊的変更の種類は、メソッドの動作が変更された動作の破壊的変更です。 この種類の変更の例としては、特定のエラーが原因でスローされる例外の変更や、浮動小数点演算の精度の変更などがあります。
.NET Framework 2.0 のすべての既知の破壊的変更が詳細に確認され、ここに記載されています。
重大な変更は、標準のコンプライアンス、顧客からのフィードバック、正確性など、さまざまな理由で行われました。 変更の文書化を徹底的に試みてきたが、これらの変更の多くはごく少数のユーザーに影響を及ぼすと考えている。 ランタイム変更の各種類の例を次に示します。
- 標準コンプライアンス: キルギスタンの System.Globalization の ISO タグが KZ から KY に更新されました。
- 標準コンプライアンス: ASP.NET の HTML レンダリングは、標準に準拠している XHTML 1.0 Transitional に更新されました
- お客様からのフィードバック: ASP.NET プロジェクト モデルは、お客様からのフィードバックに応じて変更されました。
- 正しさ： 場合によっては、浮動小数点の精度が向上しました。 これは、可能な限り CLI 仕様に既に記載されているものです。
アプリケーションの互換性に関する情報について説明し、公開するには、次の MSDN フォーラムを使用します: .NET Framework展開
アプリケーションの読み込みメカニズムと考えられる問題
既定では、.NET Frameworkを使用してビルドされたアプリケーションは、そのバージョンがコンピューターにインストールされている場合、ビルド対象のフレームワークのバージョンを使用して実行されます。 次の表は、ターゲット コンピューター上の.NET Frameworkのさまざまな構成でのアプリケーションの読み込み動作を示しています。
表 1
| アプリケーションの種類 | 1.1 のコンピューター | 2.0 のコンピューター | 1.1 および 2.0 のコンピューター |
|---|---|---|---|
| 1.1 スタンドアロン アプリケーション (Web または Microsoft Windows クライアント) | 1.1 での読み込み | 2.0 での読み込み | 1.1 での読み込み |
| 2.0 スタンドアロン アプリケーション (Web または Microsoft Windows クライアント) | 失敗 | 2.0 での読み込み | 2.0 での読み込み |
| 1.1 ネイティブ アプリケーションへのアドイン (Office やインターネット エクスプローラーなど) | 1.1 での読み込み | 2.0 での読み込み | プロセスが 1.1 に対して実行するように構成されていない限り、2.0 で読み込まれます |
| ネイティブ アプリケーションへの 2.0 アドイン (Office やインターネット エクスプローラーなど) | 失敗 | 2.0 での読み込み | 2.0 での読み込み |
.NET Framework 1.1 に対してビルドされたアプリケーション コードが.NET Framework 2.0 によって読み込まれ、重大な変更が発生した場合、アプリケーションが失敗する可能性があります。 これが可能な状況は、上の表の太字のセルによって示されます。 次のセクションでは、このような場合の潜在的な問題を軽減する方法について説明します。
.NET Framework 2.0 に対して .NET Framework 1.1 を使用して開発されたアプリケーションをテストする
アプリケーションはビルドされた Framework のバージョンを使用して実行されるため、.NET Framework 2.0 を使用してアプリケーションを実行するには、次の 2 つの可能性があります。
- .NET Framework 2.0 のみがインストールされているコンピューターにインストールしてテストします (推奨)。
- .NET Framework 1.1 が既にインストールされているコンピューターにフレームワークをインストールします。 gotdotnet.com で説明されている手順を使用して、.NET Framework 2.0 を使用してアプリケーションを強制的に実行します。
考えられる互換性の問題を軽減するための戦術
開発者は、以下に説明する戦術のいずれかに従うことで、アプリケーションが.NET Frameworkの変更の影響を受ける可能性を軽減できます。 テストの詳細については、「 互換性テストシナリオ」を参照してください。
テストと修正
常に動作します。推奨.NET Framework 1.1 に対してビルドされたアプリケーションを使用する可能性の 1 つは、.NET Framework 2.0 に対してアプリケーションをテストし、必要な変更を加え、アプリケーションが両方のバージョンのフレームワークに対して動作することを確認することです。
開発とテストの影響
これにより、2 つのバージョンのフレームワークに対してテストをチームに要求することで、アプリケーションのテスト マトリックスが拡張されます。 また、.NET Framework 1.1 と .NET Framework 2.0 の両方でアプリケーションが動作するように、開発者がソース コードを変更する必要がある場合もあります。マーケティングと運用への影響
アプリケーションの所有者は、顧客とユーザーに問題を伝え、両方のバージョンのフレームワークと互換性のある更新されたバージョンのアプリケーションを提供する必要があります。.NET Framework 1.1 を使用してデプロイする
スタンドアロン マネージド アプリケーションに対して機能します既定では、.NET Frameworkを使用してビルドされたマネージド アプリケーションは、ビルドされたバージョンで実行されます。 .NET Framework 1.1 がターゲット コンピューターにインストールされている場合、アプリケーションを変更する必要はありません。 このシナリオを有効にするには、アプリケーション所有者は引き続き、アプリケーションと共に .NET Framework 1.1 を配布 (またはフレームワークが使用可能であることを確認) するか、すべてのターゲット コンピューターにインストールされていることを確認する必要があります。
.NET Framework アプリケーションが Microsoft Office や Microsoft Internet エクスプローラー などのネイティブ ホスト内でホストされている場合、アプリケーションはコンピューターにインストールされている最新バージョンの.NET Frameworkを使用します。 これは、.NET Framework 1.1 上に構築されたアプリケーションが、.NET Framework 2.0 を使用して強制的に実行されることを意味する可能性があります。 マネージド コードをホストするネイティブ アプリケーションを直接ホスティングまたは COM 相互運用を使用して記述した場合は、ネイティブ exe を構成し、マネージド コードがビルドされたランタイム バージョンを選択できます。それ以外の場合は、コンピューターにインストールされている最新バージョンでコンポーネントを実行する必要があります。 詳細については、以下のサイド バイ サイド ドキュメントを参照してください (以前のフレームワーク バージョンをターゲットにするように exe を構成することは、インターネット エクスプローラーおよび Office アプリケーションの場合は推奨されません)。
開発とテストの影響
開発とテストの観点から見て、.NET Framework 1.1 がすべてのコンピューターにインストールされていることを確認する必要があります。 ホストされたコンポーネント (マネージド コンポーネントを読み込むアプリケーション) の場合は、.NET Framework 2.0 がコンピューターにインストールされている場合でも、ホスト プロセスが.NET Framework 1.1 を確実に読み込むよう、アプリケーションの構成ファイルを変更する必要がある場合があります。マーケティングと運用への影響
マーケティングと運用の観点からは、.NET Framework 1.1 をインストールする必要があることを伝える必要があります。 ネイティブ ホストの場合、.NET Framework 2.0 をシステムにインストールする場合は、お客様とユーザーに新しいバージョン (またはアプリケーション構成ファイルの更新プログラム) をインストールしてもらう必要があります。2.0 にアップグレードします。
すべてのアプリケーションで機能しますが、.NET Framework 2.0 が必要です.NET Framework 2.0 の新機能を利用する開発者は、.NET Framework 2.0 をターゲットにするようにアプリケーションをアップグレードする必要があります。 これには、コードの再コンパイル、アプリケーションのテスト、必要な変更の実行が含まれます。
ASP.NET 開発者は、アプリケーションを 2.0 にアップグレードする方法に影響を与える可能性があるプロジェクト システムとコンパイル モデルの変更を認識する必要があります。
開発とテストの影響
これには、破壊的変更に適応するようにアプリケーションを更新し、.NET Framework 2.0 に対してアプリケーションをテストし、.NET Framework 2.0 機能を利用するようにアプリケーションを変更する必要があります。 開発者は、アプリケーション インストール プログラムを更新して、.NET Framework 2.0 を配布する必要があります。マーケティングと運用への影響
アプリケーション所有者は、.NET Framework 2.0 と更新されたアプリケーション ビットをインストールする必要がある場合、顧客とユーザーに通信する必要があります。
潜在的なホットスポット
互換性については、次の 2 つのよく知られているホットスポットについて説明する価値があります。
- シリアル 化：シリアル化はオブジェクトの内部構造に依存するため、.NET Frameworkのバージョン間でシリアル化されたデータは脆弱である可能性があります。 これは、.NET リモート処理を介した通信のためにシリアル化されるファイルまたはデータにシリアル化されるデータに影響を与える可能性があります。 この問題が発生した場合は、共通の形式 (XML など) にシリアル化することで軽減できます。
- .NET Frameworkの特定のバージョンを確認する: セットアップ中に特定のバージョンのフレームワークがコンピューターにインストールされているかどうかをチェックするアプリケーション、または実行中の特定のバージョンの Framework に対するチェックは、バージョンが脆弱です。 これは、カスタマー アクションとして実行されているマネージド コードを活用するセットアップ プログラムの間で特に一般的な懸念事項です。
行動への呼び掛け
- 2.0 で 1.1 アプリケーションをテストし、問題があるかどうかを確認します。 このディスカッション フォーラムで問題 (特に修正がある場合) を報告する: .NET Framework展開
- このことについて顧客に話し、問題と解決策について伝えます。
付録と背景
NET Framework SDK のドキュメントと記事では、アプリケーション、Web アプリケーション、マネージド COM コンポーネントなど、特定のアプリケーション モデルに対して.NET Frameworkの特定のリリースを実行するようにアプリケーション .EXEを構成する方法について詳しく説明します。
MSDN のドキュメント
- .NET Framework開発者ガイド: .NET Framework バージョンを対象とする
- GotDotNet のビッグ レッド スイッチ情報
- ファイル情報の.Config
- .NET Frameworkの並列実行
- IIS でアプリケーションを ASP.NET する。.NET Framework開発者ガイド: ASP.NET バージョンの ASP.NET アプリケーションの構成に関するページを参照してください。
- .NET Framework 開発者ガイド: COM 相互運用のためのサイド バイ サイド実行
- 互換性に関する考慮事項とバージョンの変更
サイド バイ サイドフレームワークと機能の背景
.NET Frameworkには複数のリリースがあります (v1.0、v1.1、v2.0)。 これらの複数の.NET Framework リリースは、ユーザーが Office などの複数のバージョンのアプリケーション (たとえば、1 台のコンピューターに Office XP や Office 2003) をインストールできるのと同じ方法で、1 台のコンピューターに "サイド バイ サイド" インストールできます。 Windows XP および Windows Server 2003 では、.NET Frameworkリリースはさまざまなプロセスで並行して実行されます。 つまり、1 つのプロセスが .NET Framework 1.0 でアプリケーションを実行でき、同時に別のプロセスが.NET Framework 1.1 でアプリケーションを実行できます。
.NET Framework 1.0、1.1、2.0 でのアプリケーションの並列ランタイム動作
マネージド アプリケーション:アプリケーションが.NET Framework 1.0、1.1、または 2.0 で起動されると、CLR (mscoree) は、アプリケーションに記録された.NET Frameworkバージョンを確認し、アプリケーションがコンパイルされた.NET Frameworkのバージョンでアプリケーションの実行を試みます。 そのバージョンがコンピューターにインストールされていない場合、CLR は最新の.NET Frameworkと CLR でアプリケーションを起動しようとします。たとえば、.NET Framework 1.1 のみを持つコンピューターで実行されている.NET Framework 1.0 用にコンパイルされたアプリケーションは、.NET Framework 1.1 で実行されるようにロールフォワードされます。 同様に、.NET Framework 2.0 のみを持つコンピューターで実行されている.NET Framework 1.1 用にコンパイルされたアプリケーションは、.NET Framework 2.0 で実行されるようにロールフォワードされます。
ネイティブ アプリケーションのマネージド コンポーネント: ネイティブ アプリケーションのマネージド コンポーネントは、ネイティブ exe によって開始されたプロセス内で、ホスティング API または COM 相互運用機能を介して直接読み込まれるマネージド コードです。 マネージド コードが次の方法で読み込まれる場合、次の 2 つのメインシナリオがあります。
- シナリオ 1: マネージド コードは、ネイティブのサードパーティ アプリケーションへのアドインです
- シナリオ 2: マネージド コードはネイティブ アプリケーションの一部です
このような場合の既定の動作では、コンピューターにインストールされている最新のランタイムを読み込みます。
シナリオ 1 では、プロセス内に読み込まれる可能性のある他のマネージド コンポーネントを把握する方法がないため、マネージド アドインは読み込むランタイムを選択できず、コンピューター上で最新の状態で読み込む必要があります (Microsoft Office とインターネット エクスプローラーは、このようなアプリケーションの例です)。
ただし、シナリオ 2 では、マネージド コードは実際にはアプリケーションの一部であり、開発者はマネージド コードに必要なランタイムを正確に把握しています。 このような場合は、読み込むランタイムをアプリケーションで指定することをお勧めします。 ランタイムをホストする場合は、ホスティング API を介して (null ではなく) 正確なランタイムを指定する必要があります。 マネージ コードが COM 相互運用機能を介して読み込まれる場合、アプリケーション開発者は、サポートされているランタイムを指定する構成ファイルをネイティブ exe に配置する必要があります。
ASP.NET アプリケーション:Web アプリケーションは異なります。つまり、IIS 管理ツールを使用して特定のバージョンの ASP.NET ISAPI DLL を使用するように特定の IIS 仮想ディレクトリを構成することによって、.NET Frameworkのバージョンが選択されます。 ASP.NET ISAPI DLL は、Web アプリケーションの.NET Frameworkの対応するバージョンを読み込みます。