解説 インサイド .NET Framework ［改訂版］ 第4回　アセンブリとバージョン管理 吉松 史彰 2003/07/16 改訂（改訂前の記事はこちら）

---

本稿は、2002/07/04に公開された記事を、.NET Frameworkの新しいバージョンである「.NET Framework 1.1」に対応させ、全面的に加筆・修正を行った改訂版です。

はじめに

Back Issue

1 マネージ・コード／アセンブリ／モジュール 2 アセンブリのアイデンティティ 3 アセンブリのロード

　前回までで、アセンブリを作成し、配置し、ロードするまでの一連の流れを解説した。しかし、世のソフトウェアの常で、エンド・ユーザーのマシンにすでに配置したアセンブリには、そのあと必ず何らかの不具合が見付かる。また、新機能の追加も行われるだろう。パフォーマンスを上げるためのチューニングも行われる。その結果、アセンブリはバージョンアップする。

　ソフトウェアのバージョンアップは、開発者にとってもエンド・ユーザー（システム管理者）にとっても頭痛の種だ。バグは直してほしい。だが、その結果新しいバグが生まれていないだろうか？ ほかのアプリケーションが動かなくなってしまわないだろうか？

　今回は.NET Frameworkに組み込まれているバージョン管理機能を解説しよう。なお、バージョン管理機能は、厳密名付きアセンブリでないと使えない。あいまいな名前のアセンブリはバージョン管理の対象にならないので注意してほしい。

.NET Frameworkのバージョン・ポリシー

　これまで、開発者はソフトウェアのバージョンについて、次のような悩みを抱えていた。

• ユーザーにできるだけ新しいバージョンを使ってもらいたい。
• 下位互換性のテストはやりたくないし、完全にはできない。

　また、ユーザーはユーザーで次のような悩みを抱えていた。

• 新しいバージョンを入れた結果、既存のアプリケーションが動かなくなるのは困る。
• 新バージョンに問題がある場合は、素早く簡単に、うまく動作していた以前のバージョンに戻したい。

　.NET Frameworkには、これまでの反省が大いに活かされている。ここからは、.NET Frameworkのソフトウェアのバージョン管理方法を解説しよう。

サイドバイサイド実行とは

　.NET Frameworkにおけるバージョン管理において、中心となる考え方がサイドバイサイド実行だ（サイドバイサイド：side-by-side、「並んで、隣り合って」という意味）。サイドバイサイド実行とは、「アセンブリは決してバージョンアップしない」という原則であるといってもいいだろう。例えば次のような例を考えてみる。

　ベンダAが標準に100％準拠した超高速のXMLパーサー（Ver.1.0）をアセンブリとして公開した。また、ベンダBが、そのXMLパーサーを利用してXInclude仕様の実装を行い、やはりアセンブリとして公開した。

　そのあと、SIベンダがXIncludeをアプリケーションに組み込むために、ベンダBのアセンブリを購入した。このとき、当然ベンダAのXMLパーサーがセットで付いてきた。しかし、SIベンダはアプリケーションでそのほかのXML処理を行うために、以前よりさらに高速化されたベンダAのXMLパーサーの最新バージョン（Ver.1.2）を同時に利用した。この状況を表すと、図のようになる。このアプリケーションが実行されると、果たして何が起きるのか？！

アプリケーションのサイドバイサイド実行

バージョンの異なる2つのアセンブリを使用するアプリケーションを実行すると、何が起きるのか？

　.NET Frameworkのサイドバイサイド実行機能は、自分がコンパイルされたときに参照していたアセンブリとまったく同じアセンブリを常にロードするという機能だ。上記のアプリケーションを実行すると、メモリ上にはXMLパーサーの2つのバージョンが何の問題もなく同居する。つまりアセンブリは、同じマシンに新しいバージョンがインストールされても、それを無視して常に自分が開発されたときのバージョンを使い続けるのである。これがサイドバイサイド実行だ。自分と開発時から仲良しだったアセンブリがそのあともペアで（サイドバイサイドに）使われ続けるのだ。

　サイドバイサイド実行とは、文字通り実行時の話で、インストール時の話ではない点に注意してほしい。サイドバイサイド実行とは、「GAC（グローバル・アセンブリ・キャッシュ）に複数のバージョンをインストールできること」ではないし、「複数のバージョンが共存できること」でもない。コンパイル時とまったく同じアセンブリを使い続けることを意味する。

サイドバイサイド実行の実現

　サイドバイサイド実行が実現されるメカニズムは、実は前回までですでに解説済みだ。アセンブリの厳密名にはバージョンが含まれることを思い出してほしい。あるアセンブリが別のアセンブリを参照してコンパイルされると、参照先のアセンブリのバージョン番号がメタデータに書き込まれる。CLRはアセンブリのロード要求に応じて、バージョンも含むすべての厳密名が完全に一致するアセンブリを探してロードする。従って、バージョン番号が違うアセンブリは別アセンブリとみなされ、ロードの対象にはならない。その結果、参照先のアセンブリは常にコンパイル時のバージョンと一致することになるのだ。アセンブリは名前ごとに異なる場所にロードされるので、すでにロードされているアセンブリがバージョンの違うアセンブリの代わりになってしまうこともない。

　サイドバイサイド実行機能は、ユーザーではなく開発者に恩恵をもたらす。この機能があるおかげで、開発者は下位互換性のテストをしなくてもよくなるのだ。前のバージョンを上書きしないようにセットアップしさえすれば、古いアセンブリを使ってコンパイル、デバッグ、テストされたアプリケーションはそのまま古いアセンブリを使い続け、新しいアセンブリを使ってコンパイル、デバッグ、テストされたアプリケーションだけが新しいアセンブリを使う。古いアプリケーションから使われる可能性がないのなら、下位互換性のテストをする必要はない。

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

　

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

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