- ベストアンサー
違うディレクトリに存在するDLLを読みたい
- Visual Basic 2005で開発を行っている場合、別のディレクトリに存在するDLLを読み込む方法について求めています。
- 購入したAソフトウェアが存在し、開発したBソフトウェアがAソフトウェアのDLLを利用しているが、リリース時に問題が生じている状況についての解決策を教えてください。
- Microsoft Visual J# 2.0 再頒布可能パッケージに関しても、インストールは出来てもアプリケーションから参照することができない場合の解決策について知りたいです。
- めとろいと（@naktak）
- お礼率66% (482/721)
- Visual Basic
- 回答数2
- ありがとう数2
- みんなの回答 （2）
- 専門家の回答
質問者が選んだベストアンサー
アプリケーション構成ファイルに記述できるのも、実行ファイルがあるフォルダのサブフォルダのパスでしかないので、いずれにせよ無理ですね。 質問の答えになっていないのかも知れませんが、どう考えても a.dll を再配布するのが妥当だと思います。 購入されたのがどういう製品なのか知りませんが、大抵のものは再配布は許可されていますよ。dll として販売されている製品なのにそれが許可されていないようだと、使い物にならないと思います。再配布条件はどこかに書いてあると思いますが、わからなければ配布元に問い合わせてみればよいでしょう。 動かすだけならコピーしてもいいし、GAC にインストールする手もあるでしょう。ですが、アプリケーションの実行に必要なものは、アプリケーションと一緒に配布すべきです。それが .NET のアセンブリの配置の考え方です。 そもそも、dll 単体でインストールされるのがおかしいと思いますが…？単体でインストールされる dll なら、大抵どこからでも使えるように、GAC に自動的にインストールされるようになっているべきでしょう。
その他の回答 (1)
- ttkai00
- ベストアンサー率58% (18/31)
なるほど、少し勘違いしていました。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 ってマネージドアセンブリなんですよね？完全にそういう前提で回答していますが…
お礼
サイドバイサイドがどうたら、下位互換がどうたらという言葉はこの件について 調べていたら出てきたのですが、そういうことだったのですね。納得です。 ただそれだと一見、同じファイルが複数の場所に乱立してるような形に なるので個人的には好きになれません・・・。 販売元に確認してみたところ、作成したソフトウェアに同梱しての再配布 を想定しており、それを許可しているそうです。 また、そのdllを利用してプログラムを開発することを前提としている為 （というより、その開発を行うマニュアルすら存在する）、全く問題ない ようです。 それとすみません。お礼まで書いておいて、dllがどんなdllか書いてませんでした・・・。 マネージコードで生成されているdllなので、もうまさに的の射たご回答でした。 ありがとうございました。
お礼
ご回答ありがとうございます。 GACへの登録は全く考えておりません。意味もありませんし、手動作業という 手間が発生するので。 「Microsoft Visual J# 2.0 再頒布可能パッケージ」はtlbのおかげで 関係ないみたいでした。 今回、機器とPCが通信するソフトウェア（Aソフトウェア）を利用し、 業務アプリ（Bソフトウェア）を考えています。 Aソフトウェアをインストールすると、機器の監視ツールなどと一緒に a.dllなどがインストールされるのです。 Bソフトウェアは、そのインストールされたa.dllを利用して開発する 感じなんです。 Aソフトウェア自体は購入する必要があるのですが、それをインストール すればdllが存在するのに、なぜ別ソフトウェアでそのdllを利用する場合に 別な場所に全く同じdllが存在していなければならないのかという意味の無さと、 独自で作成したソフトウェアの同梱物としてa.dllを含めてしまって良いのか という疑問からでした。 マニュアルや著作権などが記されているファイルを確認したのですが、 明確にどうとは記されていなかった為、どうなるのが普通なのかを 知りたかったのです。 ありがとうございました。