解説 インサイド .NET Framework ［改訂版］ 第4回　アセンブリとバージョン管理 吉松 史彰 2003/07/16

---

バージョン管理機能

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

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

　第3回で解説したアセンブリのロード手順は、実はこのバージョン・リダイレクトの処理が終わってから実行される。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にリダイレクトすることができる。

バージョン・ポリシー設定（2）　−　発行者ポリシー

　アプリケーションの構成ファイルは、最初は開発者が提供するが、後でユーザーが好きなように書き換えることができる。そのため、せっかく開発者がバージョンを指定しようと思っても、アプリケーションの構成ファイルでは指定しづらい。そこで、.NET Frameworkには発行者ポリシーという仕組みが用意されている。発行者とは、開発者または販売元と考えればいいだろう。このポリシーによって、開発者がアセンブリを改良してそれをユーザーに半強制することができる。

　発行者ポリシーの内容自体は、上記の構成ファイルとまったく同じである。<bindingRedirect>要素にバージョン・リダイレクトを指定したファイルを作るだけだ。だが、その適用方法はまったく異なる。アプリケーションの構成ファイルはファイルとしてアプリケーションと同じディレクトリに配置すれば適用される。だが、発行者ポリシーはアセンブリでなければならない。

　発行者ポリシーを作るには、まず構成ファイルを作成する。構成ファイルの内容はバージョン・リダイレクトに関するものだけになるだろう。そのファイルを保存して、次にアセンブリ・リンカ（al.exe）を使ってアセンブリを作成する。例えば、構成ファイルを「policy.config」という名前で保存したとすると、次のようなコマンドをコマンド・プロンプトで実行すればよい。

% al.exe /linkresource:policy.config
/out:policy.1.0.assembly.dll /keyname:CspContainer /version:1.0

　それぞれのコマンド・オプションの意味は次の通りだ。

オプション	意味
linkresource	構成ファイルと同じ内容のファイルのファイル名を指定する。このコマンドを実行しても、出力されるアセンブリにファイルの内容が埋め込まれるわけではない。あくまでもリンクされるだけだ。/embedresourceというオプションもあるが、発行者ポリシーでは使えない
out	出力される発行者ポリシーアセンブリのファイル名。ファイル名の形式は決まっており、policy.バージョン.アセンブリのプライマリ・モジュール名という形式でなくてはならない。バージョン部分にはリダイレクトされるアセンブリの元のバージョン番号の、メジャー・バージョンとマイナー・バージョンを指定する。発行者ポリシーはメジャー・バージョンとマイナー・バージョンに対してしか機能しない
keyname	アセンブリに署名して厳密名を付けるためのCSPコンテナ（CSP：Cryptographic Service Provider）の名前（ここで解説している）。発行者ポリシーに施す署名（＝公開キー情報）は、バージョン・リダイレクトの対象となるアセンブリの署名と同じでなければならない
version	この発行者ポリシーのバージョン。リダイレクトするアセンブリのバージョンとは関係ない
発行者ポリシー作成時にアセンブリ・リンカで指定するオプション

　このコマンドを実行して出力されたアセンブリを、次のようなコマンドを実行してGACに登録しなければならない。

% gacutil -i policy.1.0.assembly.dll

　GACに登録すれば、バージョン・リダイレクトが機能するようになる。

発行者ポリシーによるバージョン・リダイレクト

アセンブリ・リンカを使用して、構成ファイルから発行者ポリシーを含むアセンブリを作成し、GACに登録する。

■発行者ポリシーのバージョン管理

　例えば、

assembly, version=1.0.0.0, culture=neutral, publickeytoken=0123456789abcdef
（プライマリ・モジュール:assembly.dll）

というアセンブリへの参照を、バージョン2.0.0.0にリダイレクトしたい場合、上記のal.exeコマンドを実行して発行者ポリシーのアセンブリを作成する。だが、そのあとで2.0.0.0のアセンブリにバグが見付かって、急遽バージョン2.1.0.0のアセンブリが作成されたような場合には、バージョン1.0.0.0をバージョン2.1.0.0にリダイレクトするような新しい発行者ポリシーを作成しなければならない。この場合は構成ファイルを作成し直して、次のコマンドを実行して発行者ポリシーを作成する。

% al.exe /linkresource:policy.config
/out:policy.1.0.assembly.dll /keyname:CspContainer /version:2.0

　バージョンに2.0を指定していることに注意してほしい。これによって、バージョン1.0.0.0を2.0.0.0にリダイレクトする発行者ポリシーがすでにインストールされている環境に、バージョン1.0.0.0を2.1.0.0にリダイレクトする新しい発行者ポリシーをインストールして使用できるわけだ。

発行者ポリシーによるバージョン管理

リダイレクトされているアセンブリを、さらに別のバージョンへリダイレクトする場合には、新しい発行者ポリシーを含んだアセンブリをGACに追加作成する。

　発行者ポリシーは、開発者から配布されるService Packのようなものだと考えればいいだろう。開発者は、新しいバージョンのアセンブリを開発したら、発行者ポリシーとセットで配布することになる。ユーザーが新バージョンのアセンブリをインストールしたときに、発行者ポリシーが同時にインストールされるようにしておくのが望ましい。

　発行者ポリシーを配布するということは、開発者が新バージョンのアセンブリと旧バージョンのアセンブリとの間の互換性テストを完全に行い、互換性があることを保証したことを意味する。これをインストールするということは、ユーザーに対してアセンブリの新バージョンを強制することにほかならない。ある意味、アセンブリのファイルを上書きするようなものだ。新旧アセンブリに互換性がない（あるいは互換性テストをしていない）場合は、発行者ポリシーを配布してはならない。

バージョン・ポリシー設定（3）　−　システム全体の構成ファイル

　システム全体の構成ファイル（マシン・ポリシー）は、アプリケーションごとではなく、そのコンピュータ全体で適用される構成ファイルだ。通常このファイルはマシン管理者が作成、編集する。このファイルは、.NET Frameworkをインストールすると、

%Systemroot%
  \Microsoft.NET
    \Framework
      \バージョン番号
        \CONFIG

のフォルダに、machine.configという名前で配置される。バージョン・ポリシーに関しては、書き込む内容はアプリケーションの構成ファイルのものとまったく同じだ。

INDEX
	解説 インサイド .NET Framework ［改訂版］
	第4回 アセンブリとバージョン管理
	1．アセンブリのサイドバイサイド実行
	2．バージョン・ポリシーによるバージョン・リダイレクト
	3．バージョン・ポリシーの適用順
	4．.NET Framework Configuration管理ツール
	5．アプリケーションの修復

　

「解説：インサイド .NET Framework ［改訂版］」

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