ケース2：参照ライブラリ構成の変更に追従する
システム開発を進めていくと、ライブラリの構成を変更せざるを得ない場合があります。構成の変更とは、もともと一つだったdllファイルを分割する、新たな機能を別のdllファイルとして追加する、複数のdllファイルに分かれていたものを統合する、などです（図7）。
図7：ライブラリ構成の変更例
dll直接配布の問題点
こういったライブラリの構成を変更する際、dllファイルを直接配布していた場合の対応方法は次のようになります（図8）。
図8：dllを配布してライブラリ構成に対応する
1. 提供者が新たなライブラリ構成で共有フォルダーにアップする
MyLib.dll一つだったところに、MyLib2.dllを追加します。
2. 利用者がライブラリ参照をやりなおす
各機能において、もともとあったMyLib.dllへの参照に加え、新たに追加されたMyLib2.dllへの参照も追加します。
このやり方では、次の問題があります。
1) ライブラリ構成変更への対応作業が煩雑
ライブラリを使用している機能が多ければ多いほど、人数が多ければ多いほど、ライブラリ変更の構成変更通知を漏れなく行き渡らせるのが大変になります。通知漏れを検出するには、ケース1でも少しふれた自動ビルドのタイミング等でビルドエラーになることを確認したり、対象全ソースのプロジェクトファイル（*.*proj）ファイルを解析して確認したりといった方法が必要になります。
また、通知が行き渡ったとしても、その対応は各機能の担当者が行わないといけません。当然規模が多くなれば対応作業のミスも増えます。
