- PR -

共通モジュール

«前のページへ 1|2|3 次のページへ»
投稿者投稿内容
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2005-10-30 16:42
引用:

迦陵頻伽さんの書き込み (2005-10-29 21:16) より:

そこで、質問の件なのですが、共通で使いたいモジュールまで
リフレクションを使っては、やはり開発時に面倒だと思うのですが、
どうにかして、解消する方法はないでしょうか？

基本的にstatic関数を『クラス名.関数名』として呼び出したいのです。

判り難い説明とは思いますが、宜しくお願い致します。

　共通で、ということは、複数のなにかが使うということですよね。では、なにが、なにを使うのでしょうか。

　この質問からは、“プラグインが”“共通のライブラリ関数を”使うとも取れますし、“複数のアプリケーションが”“共通のライブラリ関数を”使うとも取れます。
　後者のような感じではありますが、一応、念のため。
___________________________________________________________________
□ written by Jitta on 2005/10/30
□ Microsoft MVP :Visual Developer ASP/ASP.NET Oct.2005-Sept.2006
_________________
渋木宏明(ひどり)
ぬし
会議室デビュー日: 2004/01/14
投稿数: 1155
お住まい・勤務地: 東京
投稿日時: 2005-10-30 17:08
引用:

メインのアプリケーションがプラグイン用のDLLを読み込む際にフルパス指定
すればいいだけなので、構成ファイルとかは考えなくても出来ると思いますよ。


リフレクションを使う場合はそうですね。

使わなくても、キャスト程度で逃げられるのかな？
だとしても、実行時にエラーの検出が持ち越しになるのは個人的にはイヤかな。

引用:

あとは、AppDomain.AppendPrivatePathを使ってみるとか。


これがリフレクション無しな場合にも通用するようなら、簡単でよさそうですね。
迦陵頻伽
常連さん
会議室デビュー日: 2005/07/25
投稿数: 21
投稿日時: 2005-10-31 08:07
引用:

共通で、ということは、複数のなにかが使うということですよね。では、なにが、なにを使うのでしょうか。

　この質問からは、“プラグインが”“共通のライブラリ関数を”使うとも取れますし、“複数のアプリケーションが”“共通のライブラリ関数を”使うとも取れます。
　後者のような感じではありますが、一応、念のため。


想定しているのは、App以下にある全てのプログラム（メインEXEやプラグインDLL）から
[App]-[lib]ディレクトリ以下のDLLを共通で使いたいという事です。
いわた
会議室デビュー日: 2005/10/07
投稿数: 16
投稿日時: 2005-10-31 13:01
いわたです。

前回書いた内容はちょっとずれてた気もしますね。

ええと、

メインEXEが共通DLLを使用するには、何かしらの設定が必要です。
構成ファイルなり、AppendPrivatePathなり。

メインEXEがプラグインDLLを使用するには、プラグインの実装方法にもより
ますが、特別な設定は必要ない気がします。(プラグインというからには、
どのみち特定ディレクトリ配下のDLLを動的に読み込むような実装になると
思いますので。)

プラグインDLLが共通DLLを使用するには、特に設定は必要ありません。
DLLを読み込むのはあくまでメインEXEであり、メインEXEがプラグインDLLと
共通DLLを両方読み込んだ時点で、お互いにお互いを参照できるようになる
からです。

という感じだと思うのですが、まちがっていればどなたか訂正お願いします。
Jitta
ぬし
会議室デビュー日: 2002/07/05
投稿数: 6267
お住まい・勤務地: 兵庫県・海手
投稿日時: 2005-10-31 20:45
引用:

迦陵頻伽さんの書き込み（2005-10-31 08:07）より：

想定しているのは、App以下にある全てのプログラム（メインEXEやプラグインDLL）から
[App]-[lib]ディレクトリ以下のDLLを共通で使いたいという事です。

　やっぱり聞いて良かった(^-^;
　おそらく、これまで出てきている方法は、複数のアプリケーションで共通のライブラリです。プラグインが、アプリケーション提供者の提供する関数を使いたい、ということですね。

　では、プラグイン開発者には、何を提供するつもりでしょう？
　また、「共通ライブラリ」がバージョンアップしたとき、プラグインの挙動は、どのようにしましょうか？
　「プラグイン」と「共通ライブラリ」に分けた理由は、なんでしょうか。


　ご存じだと思いますが、.NET Framework 以前のモデルでは、DLL Hell という問題がありました。これを解決するために、.NET Framework では Side by Side が取り入れられています。これの難点は、使用するディスクスペースが増えることです。
　したがって、「共通で使うから、使用するディスクスペースを少なくする。ひとつ直せばすべてに変更が反映されるように、共通ライブラリにする。かつ、プラグインからは動的参照をしない。」ということであれば、要望を１００％満足することは出来ないと思います。


　あと、プラグインって、乱暴に符合させると、オブジェクト指向の「特化」だと思うんですね。なので、「特化」のための動作中であるなら、やはり個々のプラグインがその動作を実装するべきではないかと思います。
　または、プラグインは何らかのクラスを継承しなければならないようにし、親クラスに共通処理を持たせるとか。
___________________________________________________________________
□ written by Jitta on 2005/10/31
□ Microsoft MVP :Visual Developer ASP/ASP.NET Oct.2005-Sept.2006
_________________
迦陵頻伽
常連さん
会議室デビュー日: 2005/07/25
投稿数: 21
投稿日時: 2005-11-02 07:30
よく分からなくなってきました。

例えばlibディレクトリ以下にlib_sample.dllを用意したとします。
public sealed class sample
{
public static int add(int x, int y)
{
return x + y;
}
}

これをメインEXEやプラグインDLLを開発するとき、
参照の追加で、プロジェクトなりDLLを参照してあげれば、
sample.add(x, y)
という形で行き成り呼び出せますよね。

最初に質問した時点では、参照がローカルコピーになっていたため、
DLLがメインやプラグインのフォルダにまでコピーされ、
動作していましたが、これでは同じDLLが複数あり、意図していたものと違うので、
ローカルコピーされないようにし、実行したところ、DLLが参照できないので
エラーとなりました。

これをDLLのコピーやディレクトリ階層を変更することなく、GACにも登録せずに、
メインEXEやプラグインDLLを実行したときに、問題無く動作させるには
どうすればいいのかが分からないという事です。
一郎
ぬし
会議室デビュー日: 2002/10/11
投稿数: 1081
投稿日時: 2005-11-02 10:02
私は、前回の投稿で
実行した時にどのアセンブリファイルを読み込むかはHongliangさんや渋木さんが提示されているような仕組みになっています。
と書きました。

http://www.atmarkit.co.jp/fdotnet/technology/idnfw11_03/idnfw11_03_02.html
ここの「アセンブリのロード 第2段階」の節辺りから読んでみてください。
迦陵頻伽
常連さん
会議室デビュー日: 2005/07/25
投稿数: 21
投稿日時: 2005-11-02 16:02
一郎氏

一郎、その辺の記事とMSDNを検索して読んでみました。
そこで自分なりに整理した結果、今回の場合は、
GACに登録するか、設定ファイルのcodeBaseで指定するという事だと思います。

で、既に書きましたが、設定ファイルにcodeBaseを指定する方法だと、
プラグインDLLの数が増えれば増えるだけ、設定ファイルも増える？という疑問が
出た訳です。

しかし、Jitta氏の発言では、これらの出てきている方法は違うよ的な
発言があったので混乱しています。
«前のページへ 1|2|3 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）