Tweet

システム管理者のための.NET入門 第1回 なぜ.NETが必要なのか？ 2．これからの情報システムに何が必要なのか？（2） デジタルアドバンテージ　小川 誉久 2006/11/17

Side-by-SideでDLL地獄を解決し、TCOを削減する

　これまでは、直接的にはソフトウェア開発者にしか関係しない話題ばかりだったが、最後にシステム管理者に直接関係する.NETの機能を紹介しよう。

　RAD（Rapid Application Development）ツールとしてVisual Basic 6.0が広く利用されたことから、Windowsベースの業務アプリケーションでは、伝統的にC/S型のアプリケーションが多い。C/SとはClient／Serverの略で、入力フォームのユーザー・インターフェイス、ビジネス・ロジック処理などを実装したWindowsアプリケーションをクライアント側コンピュータにインストールし、ここからLAN上に配置したデータベース・サーバを直接読み書きする構成のアプリケーション・モデルである。

C/S型ビジネス・アプリケーション

C/S型アプリケーション・モデルでは、ユーザー・インターフェイスとビジネス・ロジックの処理をすべて自身で行うアプリケーションをクライアント側にインストールし、ここからLAN上にあるデータベース・サーバへ直接アクセスする。

　Visual Basic 6.0では、マウスによるドラッグ＆ドロップなどでフォームを簡単に設計できたこと、フォーム中のコントロールが操作された際の処理を比較的簡単なBasicライクな言語でプログラミングできたこと、データベース・サポート機能があり、簡単にデータベースへのアクセス・コードを記述できたことから、この方式が広く普及した。

　このC/S型アプリケーションの最大の欠点は、クライアント側のアプリケーションがすべてを抱えているため、アプリケーションの修正時にはすべてのクライアントにインストールされたプログラムを再配布して更新しなければならず、クライアントPCのTCOが増大しやすいことだ。特に、クライアントPCの台数が多い場合や、アプリケーションの改修が頻発する場合には影響が大きい。

　さらに問題を複雑化させたのは、DLL地獄（DLL hell）の問題である。Windows環境では、共有ライブラリをDLL（Dynamic Link Library）として実行プログラムから独立させ、複数の実行プログラム間でこれを共有できるようにする仕組みがある。データベース処理やネットワーク処理などは、アプリケーションによらず共通性が高いことから、DLLとして共有するのに向いている。

　これはこれで便利な機能なのだが、DLLファイルを誰かが上書きすると、これを使っている別のアプリケーションが不具合を起こすことがある。例えば、あるアプリケーションのインストールで、バージョン・チェックが正しく行われずに、古いバージョンのDLLで新しいDLLが上書きされてしまうような場合だ。この場合はDLLのバージョン・ダウンが起こるので、旧版ではサポートされていなかった機能を使っているアプリケーションが正常動作しなくなる。

　また一般に共有DLLをバージョンアップするときには、従来アプリケーションとの下位互換性は維持すべく考慮されるものだが、いつでも100％の互換性が維持されているとは限らない。この場合には、DLLを正しくバージョンアップしても、一部のアプリケーションが不具合を起こす可能性がある。

　この問題の厄介なところは、いまインストールしたアプリケーションは正しく動くのに、インストールとは無関係に見える別のアプリケーションが、突然不具合を起こすことだ。原因究明が困難で、解決も容易でない。この問題が「DLL地獄」と呼ばれるのはそのためだ。

典型的なDLL地獄の例

共有DLLを別のアプリケーションのインストーラが上書きしたため、それまで動いていたアプリケーションが突然動かなくなる。

　DLL地獄が発生してしまう根本原因は、共有ライブラリのバージョン管理をアプリケーションまかせにしており、OS側で統一的かつ完全性の高いバージョン管理メカニズムが用意されていなかったことにある。

　これに対し.NET Frameworkでは、アプリケーション用のDLLを各アプリケーションのインストール・フォルダにコピーする自己完結型にして、ほかのアプリケーションによる影響を排除できるようにした（DLLは上書きされる可能性があるが、アプリケーションの実行ファイル内にはそれが参照するDLLを識別するための情報が埋め込まれているため、DLLが開発時に参照されたものと異なる場合には、そのアプリケーションは起動できない）。

　もちろん.NET Frameworkのクラス・ライブラリをはじめとし、サードパーティ製のコンポーネント、独自に開発した共通部品など、システム全体で共有すべき共有コンポーネントは存在する。そして.NET Framework自身にも、複数バージョンがある。これらに対して.NETでは、GAC（Global Assembly Cache）と呼ばれるバージョン管理メカニズムを導入することにより、バージョン間での競合を回避できるようにしている。

　GACでは、共有コンポーネントのファイル名だけでなく、バージョン番号やカルチャ情報（対応言語）、デジタル署名の情報によりコンポーネントを管理し、たとえ同一ファイル名のコンポーネントであったとしても、バージョンやデジタル署名などが異なる場合には、別のコンポーネントとして並列インストールできるようにする。共有コンポーネントをアクセスするアプリケーション側では、自身が使用するコンポーネントのバージョン情報などを保持しており、適切な共有コンポーネントを利用する。このように複数バージョンのコンポーネントを同時インストール可能にする仕組みは、「Side-by-Sideインストール」などと呼ばれる。

　GACの実体は、%SystemRoot%\assemblyにある。このフォルダを表示してみると、同一の名前を持った複数のコンポーネントがインストールされていることが分かる。

GACの内容

同一名だが異なるバージョンのコンポーネントが同時にインストールされていることが分かる。

　以下に、IEHostという共有コンポーネントを例にとったSide-by-Sideインストールの例を示す。

Side-by-Sideインストールの例

GACでは、同一ファイル名のコンポーネントであっても、ほかの属性が異なるものについては両方をインストールし、どちらも使えるようにする。

　共有コンポーネントやDLLの配布／配置に関する問題がまったく発生しないとはいえないが、従来環境に比較すれば、.NET環境では、DLL地獄は起こりにくくなっている。多数のクライアント・コンピュータに対するアプリケーションの配布は、クライアント管理の大きな問題となっている。しかし.NET環境では、前記のような仕組みにより、共有コンポーネントやアプリケーション間での競合が発生しにくくなっており、結果として、クライアントへのアプリケーション配布に伴うTCOを大幅に削減することが可能になる。

■

　今回は、システム管理者にとって.NETがどのような存在なのか、なぜこれに注目する必要があるのかについて説明した。次回はさらに具体的に、C/S型アプリケーションやWeb型アプリケーションなど、典型的なビジネス・アプリケーションのモデルごとに、従来の問題点と、.NETがそれをどう克服するのかについて解説する予定である。

INDEX
	システム管理者のための.NET入門
	第1回 なぜ.NETが必要なのか？
	1．変化に柔軟に対応できる情報システム
	2．これからの情報システムに何が必要なのか？（1）
	3．これからの情報システムに何が必要なのか？（2）

「システム管理者のための.NET入門」

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

RSSフィード

MCPの模擬問題を解く／Windowsのセミナー、研修を探す
わたしは社外で通用するエンジニアか？→3分で診断します
［ITエンジニア年収査定］プロの鑑定で、自分の本当の価値を知る
Windowsシステム開発エンジニア：求人情報を探す
派遣エンジニア・フリーランスのための派遣求人サイト
年収MAPで市場価値を見る