解説 インサイド .NET Framework 第6回　アセンブリとバージョン管理（前編） インフォテリア株式会社 吉松 史彰 2002/07/04

---

バージョン管理機能

　開発者にとっては便利なサイドバイサイド実行も、ユーザーから見るとアプリケーションを実行した結果XMLパーサーの2つのバージョンがメモリ上にロードされるのは無駄な感じがする。また、XIncludeの実装だってより高速化されたパーサーを使いたいはずだ。しかも、XIncludeアセンブリの実装が特に変わっていないのであれば、XMLパーサー1.2を参照するようにXIncludeアセンブリをコンパイルし直すのは馬鹿馬鹿しい。SIベンダにしてみれば、ユーザーの求めに応じてXMLパーサーの最新版だけを配布し、それだけでアプリケーションが高速化することを望むはずだ。.NET Frameworkは「コンポーネント指向」なのだから、コンポーネントだけを取り替えれば再コンパイルなしで動作するはずだ。

　そこで.NET Frameworkには、アプリケーションのメタデータに記述されているバージョンとは異なるバージョンのアセンブリをロードする機能が用意されている。それがバージョン・リダイレクト機能だ。バージョン・リダイレクト機能とは、あるバージョンのアセンブリへのロード要求を、特定のバージョンへとリダイレクトする機能である。

　第4〜5回で解説したアセンブリのロード手順は、実はこのバージョン・リダイレクトの処理が終わってから実行される。CLRは、まずバージョン・リダイレクトを行って検索対象となるアセンブリの厳密名を確定し、それからアセンブリの検索処理を開始する。

　リダイレクトするバージョンの指定は、バージョン・ポリシーと呼ばれる。バージョン・ポリシーは、次の3カ所で設定することができる。

1. アプリケーションの構成ファイル
2. 発行者ポリシー
3. システム全体の構成ファイル

バージョン・ポリシー設定（1）　−　アプリケーションの構成ファイル

　アプリケーションの構成ファイルは、前々回解説したものだ。前々回の解説では、アセンブリの位置（コードベース）を特定するのに使っていた。前々回紹介したファイルにバージョン・ポリシーを設定すると次のようになる。

バージョン・ポリシーを追加したアプリケーション構成ファイル

バージョン・ポリシーを設定することにより、バージョン・リダイレクト機能を使用できる。

　<assemblyIdentity>要素に、バージョンを除く参照先のアセンブリ（依存アセンブリ；dependentAssembly）の名前を設定し、<bindingRedirect>要素で旧バージョンとリダイレクト先の新バージョンを指定する。この場合は、「メタデータでバージョン1.0.0.0のutilアセンブリを参照している場合、バージョン2.0.0.0のアセンブリを代わりにロードする」という指定になっている。

構成ファイルにおけるリダイレクトの指定

この設定では、メタデータでバージョン1.0.0.0のアセンブリを参照している場合、バージョン2.0.0.0のアセンブリを代わりにロードする。

　このファイルは、ユーザーが構成するファイルだ。つまり、アセンブリの開発者の意思に関係なく、利用者がどのバージョンのアセンブリをロードするのかを指定できるということだ。これによって、XIncludeアセンブリの開発者が新バージョンのXMLパーサーを利用するようにアセンブリを作成し直してくれるのを待たなくても、利用者が独自に構成ファイルを書いて、適切なバージョンのアセンブリへ処理をリダイレクトすることができるのだ。

　なお、旧バージョン（oldVersion）の部分には、「バージョン-バージョン」のようにハイフンで区切ってバージョンの範囲を指定することもできる。例えば1.0.0.0-1.9999.9999.9999の範囲のすべてのバージョンを2.0.0.0にリダイレクトすることができる。

INDEX
	解説 インサイド .NET Framework
	第6回　アセンブリとバージョン管理（前編）
	1．アセンブリのサイドバイサイド実行
	2．構成ファイルによるバージョン管理
	3．発行者ポリシーによるバージョン管理

　

「解説：インサイド .NET Framework 」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）