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

---

バージョン・ポリシー設定（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という名前で配置される。バージョン・ポリシーに関しては、書き込む内容はアプリケーションの構成ファイルのものとまったく同じだ。

　さて、以上のようにバージョン・ポリシーは3カ所で設定することができる。では、ポリシーが同時に複数存在する場合には、それらはどのように適用されるのか？ 次回後編では、このバージョン・ポリシーの適応順や、バージョン管理に役立つ管理ツールについて解説を行う。

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

　

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

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