違うディレクトリに存在するDLLを読みたい

質問

Visual Basic 2005で開発を行っています。

開発の時点では参照設定よりDLLを読み込んでいるので問題ないのですが、
リリース時に問題があって困っています。

例えば
・購入したAソフトウェア（a.dll）が存在する。
・開発したBソフトウェア（b.exeとb.dll）が存在する。
・Bソフトウェアのb.exeは、Bソフトウェアのb.dllを利用しており、
　Bソフトウェアのb.dllは、Aソフトウェアのa.dllを利用している。
・AソフトウェアとBソフトウェアのインストールタイミングは別である。
・Aソフトウェアがインストールされた先はC:\Program Files\A_Software\a.dllである。
・Bソフトウェアがインストールされた先はC:\Program Files\B_Software\b.exe（b.dll）である。

このような場合に、b.exeはb.dllを解決することが出来ますが、
b.dllはa.dllを解決することが出来ません。
また、a.dllはデフォルトインストール先はありますが、Bソフトウェアと
インストールタイミングも別な為、どこにインストールされてくるか
分かりません。
その為、アプリケーション構成ファイルに参照パスなるものを指定して
おくことも出来ません。

こういった場合、Bソフトウェアをインストール後に、Aソフトウェアのインストール先から
a.dllをBソフトウェアのインストール先へコピーするなどという手動的作業が
必要になるのでしょうか？
インストーラーを作成する場合にa.dllを含めてしまうとライセンスが
問題になることが多いと思います。

Microsoft Visual J# 2.0 再頒布可能パッケージ
http://www.microsoft.com/downloads/details.aspx?FamilyID=f72c74b3-ed0e-4af8-ae63-2f0e42501be1&displaylang=ja
これに関しても、インストールは出来てもアプリケーションから参照
出来ないというのではお話にならないと思うのですが、
どうやって解決しているのでしょうか？

宜しくお願い致します。

回答No.1

ttkai00 · ベストアンサー

アプリケーション構成ファイルに記述できるのも、実行ファイルがあるフォルダのサブフォルダのパスでしかないので、いずれにせよ無理ですね。

質問の答えになっていないのかも知れませんが、どう考えても a.dll を再配布するのが妥当だと思います。

購入されたのがどういう製品なのか知りませんが、大抵のものは再配布は許可されていますよ。dll として販売されている製品なのにそれが許可されていないようだと、使い物にならないと思います。再配布条件はどこかに書いてあると思いますが、わからなければ配布元に問い合わせてみればよいでしょう。

動かすだけならコピーしてもいいし、GAC にインストールする手もあるでしょう。ですが、アプリケーションの実行に必要なものは、アプリケーションと一緒に配布すべきです。それが .NET のアセンブリの配置の考え方です。

そもそも、dll 単体でインストールされるのがおかしいと思いますが…？単体でインストールされる dll なら、大抵どこからでも使えるように、GAC に自動的にインストールされるようになっているべきでしょう。

お礼

ご回答ありがとうございます。
GACへの登録は全く考えておりません。意味もありませんし、手動作業という
手間が発生するので。

「Microsoft Visual J# 2.0 再頒布可能パッケージ」はtlbのおかげで
関係ないみたいでした。

今回、機器とPCが通信するソフトウェア（Aソフトウェア）を利用し、
業務アプリ（Bソフトウェア）を考えています。
Aソフトウェアをインストールすると、機器の監視ツールなどと一緒に
a.dllなどがインストールされるのです。
Bソフトウェアは、そのインストールされたa.dllを利用して開発する
感じなんです。

Aソフトウェア自体は購入する必要があるのですが、それをインストール
すればdllが存在するのに、なぜ別ソフトウェアでそのdllを利用する場合に
別な場所に全く同じdllが存在していなければならないのかという意味の無さと、
独自で作成したソフトウェアの同梱物としてa.dllを含めてしまって良いのか
という疑問からでした。

マニュアルや著作権などが記されているファイルを確認したのですが、
明確にどうとは記されていなかった為、どうなるのが普通なのかを
知りたかったのです。

ありがとうございました。

回答No.2

ttkai00

なるほど、少し勘違いしていました。DLLとして販売されているものではなく、別のソフトのDLLを利用しようというお話でしたか。つまりBは、Aを自分で購入して所持しているユーザー向けに配布されるということですよね。

ではそもそも、Aの中にあるそのDLLは、ユーザーがそれを使用してプログラムを開発されることを前提としているようなものなのでしょうか？もしそうなら、再配布が可能かどうか、販売元に確認してみるのが一番だと思います。

もしそうでなければ、そういうものは用意されておらず、再配布も許可されない可能性が高いと思います。その場合そもそも、そういうソフトの開発自体を行っていいのかどうかも怪しいです。

再配布が許可されない場合、どうしてもやるとしたら、Bのインストーラのカスタム動作等で、A のインストールフォルダをユーザーが指定できるようにして、コピーするとかでしょうか。

ただし、それがライセンス違反になるのかどうかとか、そういう話については、私は詳しくないので回答できません。

> なぜ別ソフトウェアでそのdllを利用する場合に
> 別な場所に全く同じdllが存在していなければならないのか

先にも書いた通り、アプリケーションの実行に必要なものは、アプリケーションと一緒に配布し、アプリケーションのディレクトリに配置するのが .NET の考え方です。

これはサイド・バイ・サイドと呼ばれるアセンブリのバージョン管理の考え方から来ているものです。仮にAのインストールフォルダにある a.dll を参照設定できたとして（実際にはできません）、もしBのインストール後にAをバージョンアップして a.dll のバージョンが変わると a.dll を読み込むことができなくなります。

.NET では a.dll というファイル名で参照するのではなく、厳密名と呼ばれるものでアセンブリを参照します。厳密名はアセンブリ名、バージョン名、公開キーを含んでいるため、バージョンが違うとそれは別のアセンブリとみなされてロードできなくなるのです。

というわけで、今回のケースでは、仮に全く同じ a.dll であったとしても、自アプリケーションのディレクトリに同じものを置くのが .NET では普通の考え方です。これならAがバージョンアップされても動かなくなったりすることもありませんし、AとBを同時に使用することもできます。この場合、Aが参照している a.dll と Bが参照している a.dll のバージョンが異なりますが、正しく動作します。これをサイド・バイ・サイドといいます。

ちなみにこれは、a.dll が厳密名を持っていると仮定しての話です。厳密名を持っていない場合は、「a.dll」という名前のみで参照されます。販売されているようなものなら、大抵は厳密名を持っていると思います。

ところで、a.dll ってマネージドアセンブリなんですよね？完全にそういう前提で回答していますが…

参考URL：

http://www.atmarkit.co.jp/fdotnet/technology/idnfw11_02/idnfw11_02_01.html

お礼

サイドバイサイドがどうたら、下位互換がどうたらという言葉はこの件について
調べていたら出てきたのですが、そういうことだったのですね。納得です。
ただそれだと一見、同じファイルが複数の場所に乱立してるような形に
なるので個人的には好きになれません・・・。

販売元に確認してみたところ、作成したソフトウェアに同梱しての再配布
を想定しており、それを許可しているそうです。
また、そのdllを利用してプログラムを開発することを前提としている為
（というより、その開発を行うマニュアルすら存在する）、全く問題ない
ようです。

それとすみません。お礼まで書いておいて、dllがどんなdllか書いてませんでした・・・。
マネージコードで生成されているdllなので、もうまさに的の射たご回答でした。
ありがとうございました。