.NET Frameworkのサイド バイ サイド実行

  • [アーティクル]

 

Dennis Angeline
Microsoft Corporation

2002 年 12 月

適用対象:
   Microsoft® .NET® Framework
   Microsoft Visual Studio® .NET 2002

概要：.NET Frameworkの並列実行に関する詳細な情報は、.NET Frameworkアプリケーションまたはコンポーネントを構築または構成している個人を対象としています。 (6 ページ印刷)

内容

用語
詳細情報
アプリケーションを構成する方法の決定
Windows クライアント アプリケーションの構成
アンマネージド アプリケーションの構成
Web アプリケーションの構成
詳細情報

用語

1.0 アプリケーションは、.NET Frameworkのバージョン 1.0 を対象とするアプリケーションです。 Visual Studio .NET 2002 でビルドされたすべてのアプリケーションは 1.0 アプリケーションです。

1.1 アプリケーションは、.NET Frameworkのバージョン 1.1 を対象とするアプリケーションです。 Visual Studio .NET 2003 でビルドされたすべてのアプリケーションは、1.1 アプリケーションです。

詳細情報

.NET Frameworkに組み込まれているサイド バイ サイド サポートにより、複数のバージョンのフレームワークを 1 つのシステムにインストールできます。 .NET Frameworkのバージョン 1.1 のリリースでは、アプリケーションとコンポーネントの開発者は、フレームワークの複数のバージョンがインストールされているシステムでコードがどのように動作するかを検討する必要があります。

1.1 フレームワークは、1.0 Framework と高い互換性を持つように設計されています。 Microsoft は、1.0 Framework 上に構築されたアプリケーションの大部分が 1.1 Framework で引き続き動作するように、非常に長い時間を経過しています。 これには、パブリック型と API よりも深いレベルでの互換性が含まれます。 たとえば、互換性にも影響を与える可能性がある API の実装の変更を厳密に監視します。 したがって、先行タスクによって返されなかった値を返す API は、互換性がないものと見なされます。

互換性を維持するためにあらゆる努力が行われていますが、互換性を損なうために開発チームが絶対に必要だと判断した場合もあります。 これは、変更の影響を徹底的に分析した後、最も深刻なケースでのみ行われます。 破壊的変更は通常、セキュリティ関連の問題や既存の機能の重大な欠陥に対処するための最後の手段としてのみ行われます。 API の一貫性や外観を改善したり、他の合理的な方法で対処できるバグを修正したりするために、破壊的変更は行われません。 互換性が影響を受ける場合は常に、Microsoft は変更を公開し、潜在的な回避策を提供します。 1.1 Framework の破壊的変更の完全な一覧は、 にあります https://www.gotdotnet.com/team/changeinfo/Backwards1.0to1.1/default.aspx。

1.0 と 1.1 Framework の間の高度な互換性にもかかわらず、1.0 Framework を使用するほとんどのアプリケーションは、1.1 Framework のインストール時に自動的にアップグレードされません。 実際、新しいバージョンの.NET Frameworkをインストールしても、ほとんどの種類の既存のアプリケーションには影響しません。 1.1 Framework は、1.0 Framework を使用しているアプリケーションに影響を与えずにシステムからインストールまたはアンインストールできるように設計されています。 同様に、1.1 バージョンのフレームワークでビルドされたアプリケーションは、古いフレームワークがインストールされている場合には影響を受けません。

メモ 古いバージョンのフレームワークをアンインストールすると、そのバージョンに依存し、新しいバージョンと完全に互換性がない既存のアプリケーションに影響を与える可能性があります。

Side-by-side 実行により、アプリケーション開発者とシステム管理者は、新しいバージョンのフレームワークを使用するように既存のアプリケーションを必要に応じて構成できます。 あるバージョンのフレームワークを別のバージョンで使用するという決定は、アプリケーション開発者または管理者のみが特定のアプリケーションのコンテキストで行うことができる決定であると考えています。 つまり、真の互換性は、特定のアプリケーションのコンテキストでのみ評価できます。

そのため、アプリケーションは新しいバージョンのフレームワークでテストでき、アプリケーション開発者または管理者がテストの結果に基づいて適切であると判断したときに、新しいバージョンで動作するように構成できます。 2 つのバージョン間の互換性が高いため、1.0 または 1.1 Framework と同等に動作する 1.0 アプリケーションの大部分が完全に期待されています。 アプリケーションが 1.1 Framework で動作しないまれな場合は、1.0 Framework のみをサポートするようにアプリケーションを構成できます。 したがって、アプリケーション開発者は、1.1 Framework を使用してアプリケーションをテストし、必要に応じて、1.0 または 1.1 またはその両方で動作するようにアプリケーションを構成するように促されます。

バージョン 1.0 アプリケーションは 1.1 Framework で実行することが完全に期待されていますが、バージョン 1.0 Framework で 1.1 アプリケーションを実行することははるかに困難です。 これを機能させるには、1.0 Framework で使用できない新機能の使用を避けるために、開発者側でかなりの努力が必要です。 1.1 Framework でのみ見つかる機能を使用するアプリケーションは、単に 1.0 Framework では動作しません。 これらの機能の一覧は、 にあります https://www.gotdotnet.com/team/changeinfo/Forwards1.0to1.1/default.aspx。

アプリケーションを構成する方法の決定

必要なアプリケーション構成の方法は、ビルドするアプリケーションの種類によって異なります。 従来の Windows™ クライアント アプリケーション (Windows フォーム、コンソール アプリケーション、および Windows サービス) は、アプリケーション構成ファイルで構成されます。 Web アプリケーション (ASP.NET および XML Web サービス) は、インターネット インフォメーション サービス (IIS) 管理者を介して構成されます。

Windows クライアント アプリケーションの構成

アプリケーション開発者または管理者は、アプリケーション構成ファイルを指定することで、1.0 Windows クライアント アプリケーションを 1.1 Framework にテストまたは完全にリダイレクトできます。 アプリケーション構成ファイルは、共通言語ランタイム (CLR) に、アプリケーションのプロセスに特定のバージョンの.NET Frameworkを読み込むよう指示できます。 実行時に読み込まれるフレームワークのバージョンは、アプリケーションが実際にコンパイルされたバージョンとは異なる場合があります。

アプリケーション構成ファイルは、アプリケーション実行可能ファイル (.exe) ファイルと同じディレクトリにある.xml ファイルです。 構成ファイル名は、末尾に ".config" が付加された.exeファイル名と同じである必要があります。 たとえば、アプリケーション MyApp.exeには MyApp.exe.config という名前の構成ファイルがあるとします。構成ファイルには、実行する必要があるフレームワークのバージョン以外のアプリケーションの動作の他の側面に影響する設定を含めることができます。

フレームワークのバージョンは、構成ファイル内の スタートアップ セクションの内容の影響を受けます。 特に、 supportedRuntime 要素は Framework バージョンの選択に影響します。 スタートアップ セクションには、1 つ以上の supportedRuntime 要素を含めることができます。各要素は、アプリケーションがサポートするフレームワークのバージョンを指定します。 supportedRuntime 要素は、優先順に並べ替わります。 言い換えると、フレームワークの最も優先されるバージョンが最初に一覧表示されます。 たとえば、1.0 と 1.1 の両方のフレームワークをサポートしているが、1.1 Framework を使用することを好むアプリケーションでは、アプリケーション構成ファイルのスタートアップ セクションに次の内容が含まれます。

<configuration>
…
<startup>
   <supportedRuntime version="v1.1.4322" />
   <supportedRuntime version="v1.0.3705" />         
</startup>
…
</configuration>

supportedRuntime 要素で指定されたバージョン番号は、Framework がインストールされているサブディレクトリと一致する必要があります。 たとえば、バージョン 1.0 Framework はディレクトリ C:\Windows\Microsoft.Net\Framework\v1.0.3705 にインストールされます。そのため、構成ファイルで指定されたバージョン番号は "v1.0.3705" です。 同様に、1.1 Framework は C:\Windows\Microsoft.Net\Framework\v1.1.4322 ディレクトリにインストールされます。 サポートされているランタイム バージョン番号に ワイルドカード は使用できません。 そのため、まだリリースされていないバージョンのフレームワークをサポートするようにアプリケーションを構成することはできません。

メモ 新しいバージョンの Framework がベータ テスト用にリリースされると、バージョン番号が利用可能になります。

CLR は、アプリケーションの.config ファイルに記載されているバージョンと、アプリケーションが実行されているシステムで使用できるバージョンに基づいて、読み込むフレームワークのバージョンを決定します。 構成されたアプリケーションは、supportedRuntime リストに含まれていないフレームワークのどのバージョンでも実行されません。 構成は、アプリケーションがデプロイされる前または後にいつでも変更できます。 ファイルに含まれる設定がアプリケーションの動作の他の側面に影響を与える可能性があるため、構成ファイルを変更する場合は注意が必要です。

未構成の Windows クライアント アプリケーション

構成ファイルまたは少なくとも supportedRuntime 要素を含まないアプリケーション (構成されていないアプリケーション) は、そのバージョンのフレームワークがローカル システムにインストールされていれば、アプリケーションのビルドに使用されたバージョンの Framework で実行されます。 (アプリケーションがビルドされたフレームワークのバージョンは、アプリケーション .exe ファイルのヘッダーに含まれています)。そのバージョンのフレームワークが使用できない場合、CLR では、その代わりに新しいバージョンのフレームワークが使用されます。 言い換えると、Framework 1.0 でビルドされた未構成のアプリケーションは、1.0 と 1.1 の両方がインストールされているシステムで 1.0 で実行されます。 同じアプリケーションは、1.1 Framework のみがインストールされているシステム上の 1.1 Framework で実行されます。 互換性があると見なされるすべてのバージョンのフレームワークをサポートするようにアプリケーションを構成し、ターゲット コンピューターで特定のバージョンを使用できるシナリオを提供することを強くお勧めします。 アプリケーションは、.NET Frameworkの再配布に関するページで説明されているように、必要な.NET Frameworkのバージョンを再配布することで、このような状況に対応することもできます。

使用できる適切なバージョンはありません

アプリケーションの実行に適したバージョンのフレームワークが見つからない場合、CLR には、アプリケーションがサポートするフレームワークのバージョンを一覧表示するダイアログ ボックスが表示され、一覧表示されているバージョンのいずれかをインストールするようにユーザーに求められます。 このダイアログは、レジストリで NoGuiFromShim キーを設定することで抑制できます。

HKLM\\Software\\Microsoft\\.NETFramework\\NoGuiFromShim = 1

アンマネージド アプリケーションの構成

多くのアンマネージド Windows クライアント アプリケーション (.NET Frameworkを使用して構築された Windows クライアント アプリケーションではなく、代替プログラミング モデル) では、COM Interop を介してマネージド コンポーネント (.NET Frameworkを使用して構築されたコンポーネント) のサービスが使用されます。 インターネット エクスプローラー内で表示される Web ページでマネージド コンポーネントをホストすることは、マネージド コンポーネントのサービスを使用するアンマネージド アプリケーション (インターネット エクスプローラー) の完全な例です。 インターネット エクスプローラーを使用したタッチなしの展開を通じてデスクトップに展開されるマネージド Windows クライアント アプリケーションも、もう 1 つの例です。 管理されていないホスト アプリケーションはすべて、マネージド コンポーネントに特定のバージョンのフレームワークを使用するように構成できます。 既定では、コンポーネントがアンマネージド アプリケーションによって読み込まれると、マネージド コンポーネントが、使用可能な最新バージョンの Framework と共にアプリケーションのプロセスに読み込まれます。 この動作は、前に説明したマネージド Windows クライアント アプリケーションの動作とは多少異なります。 フル マネージド アプリケーションとは異なり、アンマネージ .exes には、問題のコードがビルドされたフレームワークのバージョンを記述する情報がヘッダーにありません。これにより、CLR は、使用可能な最新バージョンのフレームワークを読み込む以外の選択肢はありません。

ただし、コンポーネントにフレームワークの非常に特定のバージョンが必要な場合は、コンポーネントをホストするアンマネージド .exe (インターネット エクスプローラーなど) に対して、前述のような構成ファイルを提供できます。 構成ファイルは、マネージド コンポーネント自体ではなく、コンポーネントをホストする.exeに存在する必要があることに注意してください。 最終的には、これは、特定のアンマネージド アプリケーションによって呼び出されるすべてのマネージド コンポーネントが、使用可能な最新バージョンまたはアプリケーションの.config ファイルで指定されたバージョンの Framework で実行されます。 これらの構成ファイルは、前に示した XML の例を使用して最初から作成できます。 .config ファイルの名前は、[アンマネージド アプリの Exe 名] .exe.config (例: iexplore.exe.config) と同じ方法で指定する必要があります。

Web アプリケーションの構成

Web サーバーは、.NET Framework (つまり、ASP.NET ライブラリ) を使用して構築された個々の Web サイトごとに個別のバージョンの.NET Frameworkを使用するように構成できます。 特定のサイト内で実行されるすべてのコードでは、そのサイトに対して指定されたバージョン、またはサイトに対してバージョンが指定されていない場合はサーバーに対して指定されたバージョンが使用されます。

構成ファイルを使用してフレームワークのバージョンを選択するのではなく、各サイトの構成は、ASP.NET ISAPI フィルターの特定のバージョンを選択することで IIS 管理コンソール内で設定されます。 ASP.NET フィルターは、[Web サイトのプロパティ] ダイアログの [ISAPI フィルター] タブで設定されます。 フィルターは、個々のサイトに対して設定できます。 ルート Web サイトでフィルターを変更することで、Web サーバー全体に対して設定することもできます。 ASP.NET フィルターは、ファイル aspnet_filter.dllに実装されます。 1.0 フィルターは%windir%\ Microsoft.Net\Frameworks\v1.0.3705 ディレクトリにあります。 1.1 フィルターは%windir%\ Microsoft.Net\Frameworks\v1.1.4322 ディレクトリにあります。

バージョン 1.1 Framework をインストールすると、1.1 ASP.NET フィルターが Web サーバーのルート Web サイトのフィルター リストに自動的に追加されます。 ルート レベルでフィルターを更新すると、個別に構成されていないすべてのサイトが、1.1 バージョンのフレームワークの使用を開始します。 1.0 Frameworks を引き続き使用する必要があるサイトは、1.0 ISAPI フィルターを使用するように個別に構成する必要があります。 ISAPI フィルターの構成は、Web サイト レベルでのみ行うことができます。 異なる ISAPI フィルターを使用するように個々の VRoot を構成することはできません。

詳細情報

サイド バイ サイドの構成例の詳細については、「」を参照してください https://www.gotdotnet.com/team/changeinfo/default.aspx。