■ DLL Hell の終焉

  • DLL Hell とは
  • DLL Hell の原因
  • そして、DLL Hell の終焉

DLL Hell とは

簡単に言うと、DLL Hell (地獄) とは、DLL のバージョンアップによって、前のバージョンを利用していたアプリケーションが動かなくなってしまうことや、それを避けるためにバージョンごとに別々の DLL ファイルを作成した結果、システムディレクトリに同じような DLL があふれかえってしまう状況を指します。

DLL Hell の原因

もともと、DLL (Dynamic Link Library) は多くのシステムで利用されている、ディスクやメモリの節約を可能にするコンパイル済みのライブラリを提供するための技術です。

この DLL を使用することで起きる DLL Hell は、COM で解決される予定でした。COM のインターフェイスの決まりに則って正しく COM を作成し、インストーラを使って正しくインストールしていれば、こういった問題は解決されたはずです。しかし、実際にはこの問題は根絶することはできませんでした。

原因として考えられることは、本来守るべきルール (「COM ではインターフェイスを変えてはいけない」 「下位互換性を保たなければいけない」 など) を守らなかった設計者やプログラマのミスをあげることができます。

もっと基礎的な問題として、きちんと DLL をインストールせずに、ファイルを単純に上書きしてしまったというような原因もあるかもしれません。そこまでひどくないにしても、インストーラがきちんとバージョンをチェックせずに DLL をコピーしたときにも同様の状態になります。

そして、DLL Hell の終焉

この問題を解決するため、"プライベート DLL" という考え方があります。これはアプリケーションが利用する DLL を各々のフォルダなどに配置するというものです。これを Side-By-Side 配置と呼びます。これにより、たとえば同じ DLL が別のフォルダに配置され、しかも、それらを利用するアプリケーションが起動しているとき、同じ名前の異なるバージョンの DLL がシステム上で同時に実行されることが可能になります。

.NET Framework では、このプライベート DLL の考え方を拡張して、DLL Hell に終わりを告げます。

まず、共通言語ランタイムは、同じ DLL の異なるバージョンを管理することができ、それらが同時に実行されることもできるようになっています。

そして、DLL を利用する側でも、コンパイル時に、必要なライブラリのバージョンの情報がコンパイルしたモジュールに含められます。これにより、必ず正しい DLL が利用されることになります。さらに、バージョンポリシーを利用して、その DLL の最新のバージョンを利用するように指定したり、ある特定のバージョンを指定したりすることもできます。

また、Visual Studio .NET には適切なデプロイメント (配置) を簡単に行なえるインストーラも存在しますので、これを利用することができます。

まとめ

Visual Basic 6.0 で正しく COM コンポーネントを作成し、ディストリビューションウィザードを使ってきちんと配布していた場合、DLL Hell は終わっていたのかもしれません。そのような方にとっては、.NET Framework は COM の代わりにより、確実な新しい方法で、DLL Hell を解消することにしたと捉えることができます。