元ネタ：dllの参照方法

xuexueさん (2006/12/28(Thu) 17:53:59)：

なんでローカルにdllがおりてきちゃうのか疑問でなりません。
だって、dllがバージョンアップしたら、いちいち配置してあげないと・・ですよね。

はぁ。。。

「DLL Hell」という言葉を、ご存じでしょうか。こいつを回避するため、.NET Framework では、複数のアプリケーションで共通して使う DLL は、Global Assembly Cache に登録するか、アプリケーションの実行ファイルがあるところにコピーするように、強く推奨されています。

では、DLL Hell とは、どんなものでしょうか。私の体験を、書きます。

1997年でしたか。あるプロジェクトで、DateTimePicker を使うことになりました。テキスト ボックスに年月日が出ていて、クリックするとカレンダーが出てくるヤツです。

これを使ってアプリを作り、「出来ました！」と、品質保証部へ回したところ、「カレンダーで、なんにも選ばずにカレンダーの外をクリックすると、アプリケーションが落ちるんだけど？」

いや、あの、その。。。それって、Borland から提供してもらっている部品なんで。。。早速 Borland へ問い合わせる。返事有り。「マイクロソフトが提供している部品なので、弊社では修正いたしかねます」・・・が～～～～ん！！

というわけで、元になる DLL を特定し、その DLL の、他のバージョンがないか、探す。

あった。「一太郎」についてきたものが、バージョンが新しい。

早速テスト。良好良好。

「修正しました！！」と、渡す。「この、日付のあるところで、IME をオンにして、キーボードの上に手を置く（複数のキーを同時に押す）と、アプリケーションが落ちるんだけど？」

え゛？！そんなテスト、するですか？

ってことで、さらに他のバージョンがないか、探す。あった。MS Office と共にインストールされるものが、さらに新しい。

早速入れ替えてテスト。同時押しは直っている。が。カレンダー外クリックが復活しているorz

結局。テキスト ボックスを３つ並べましたよ。UI の悪さより、安定性を選んだわけです。

数ヶ月後。Borland のサイトで、カレンダー外クリックの対処方法が書かれているのを発見。さらにへこむ。

・・・・・

まぁ、このときは、結局直らなかったわけですが。

一太郎バージョンで不具合が出ず、その状態で出荷したとします。後で顧客が MS Office をインストールしたら？また、不具合が発生するわけです。

このように、DLL のバージョンによって、あるアプリケーションの挙動が左右されるような状態。そんな状態に、好きこのんでなりたいですか？

このような状態を回避するため、.NET Framework では、DLL を実行ファイルがあるのと同じディレクトリにコピーするようにしました。こうして、アプリケーションと DLL が同時に更新されるようにすることで、あるアプリケーションのための変更が、他のアプリケーションへ害を及ぼすことを阻止できます。

そもそも、DLL とは、Dynamic Link Library、実行時結合型のライブラリです。コンパイル時に結合されるライブラリは、LIB という拡張子が付けられています。

静的にリンクすると、ローカルにコピーしたモノを使うのと同じで、特定のバージョンを使い続けることが出来ます。しかし、なぜ、動的に結合するものが必要なのか。

ディスク資源の節約です。共通のものは外に追い出し、都度都度参照することで、配布するときにその分の容量を減らすことが出来ます。

元々、ディスク資源を有効に使うために作った仕組みなのに、同じディレクトリにコピーしていては元の木阿弥です。なので、GAC に登録して、共通して使うことが出来るようにしてあります。

ところで、UNIX の世界にも静的ライブラリと動的ライブラリはあります。しかし、うろ覚えですが（指摘求む）、UNIX の場合、動的ライブラリには、拡張子の後にバージョン番号が追加されています。コンパイル時に、実行時に結合するライブラリのバージョンを指定することが出来るんですね。

マイクロソフトは、なぜこれをマネしなかったのか。なぜ今頃になって、ようやくマネをしたのか。

簡単です。ディスク資源が足りなかったのです。ファイル名も、8.3の 11文字しか使えなかったし。NTFS でファイル名の制限をなくし、ディスク資源が潤沢になった今になって、既存の Win32 アプリケーションに影響しない .NET Framework という別の基盤を使って、ようやくマネすることが出来るようになったのです。

しかし、GAC に登録するためには、バージョンを明確にしなければなりません。あと、署名も必要。なぜでしょうか。

出所のはっきりしない DLL を使って、本当に大丈夫なんですか？誰かが、同じ名前で、同じ関数を持つ、違う動きをする DLL を作って、こっそり配布したら、どうなりますか？

あるいは。本当に、「修正した」DLL が、他のアプリケーションでも使えるのですか？インターフェイスが変わったりしていませんか？少し古い開発者なら、SUCCESS の定義が変わってあたふたした憶えがないですか（私はこのとき、まだ UNIXer だったので、人ごとでしたが）。0 と定義されていた SUCCESS を、1、つまり true と同じにしたんですね、確か。これ、SUCCESS で見ていれば、コンパイルし直すだけで済みますが、0 や 1 をハードコーディングしていたら・・・

もう一度尋ねます。こんな体験、したいですか？