- 締切済み
共有DLLの参照方法
共有DLLのインストールパスが変わる(Windowsがインストールされたパーティションのマッピングの違い,X86とX64の違い,ユーザーがカスタムインストールしているなど) EXEとの相対パスが変わる(ZIPで圧縮されている場合の回答位置など) DLLの種類やその中に含まれるクラスなどの定義は変わらない レジストリなどを介してファイルパスはわかる という事になるわけですがこういった場合の参照はどのように追加すればよいのでしょうか? どぼん氏のプラグイン機能を持つアプリケーションを作成するのような実装では インターフェースをEXEか別のDLLでインターフェースをクラス分全て持たなければならない インターフェースを持つDLLと共有DLL、インターフェースを持つDLLとEXEの双方の相対パスが変えられない またはインターフェースを持つDLLの絶対パスが変えられない といった問題が回避できませんでした。 環境はWindows Vista x64+Visual Studio 2005です。
- izayoimizuki
- お礼率67% (46/68)
- Visual Basic
- 回答数1
- ありがとう数3
- みんなの回答 （1）
- 専門家の回答
みんなの回答
- K-Sogacchi
- ベストアンサー率53% (50/93)
ピッタリあてはまるかどうかは、わからないですが… System.ReflectionのAssemblyオブジェクト等を使用すれば、直接ファイル名で Load出来るので、何とかなるかもしれません。 詳細は以下のページ内の「リフレクション」の部分辺りを参照してください。 http://dobon.net/vb/dotnet/index.html#programing ただ、私もうろ覚えなんですが、この方法は実装がかなり面倒です。 必要なメソッド、プロパティの名前がわかっていれば、その辺りは面倒でも何とかなるんですが、 イベントをハンドルしようとすると、確かデリゲートを使って、イベントを イベントハンドラに何とかして結び付けなければいけなかったはず。 ちなみに私の場合は、昔「DLLがあっても無くても、それなりに動くようにしてくれ」と 言われて、かなり難儀した覚えがあります。
関連するQ&A
- Delphi6 DLL内でのメモリ共有(?)
こんにちは、honiyonです。 複数アプリケーションからそれぞれコールバック関数を登録してもらい、状況に応じてそれぞれのコールバック関数を呼び出す、というDLLを作成しています。 しかし現在、呼び出しアプリケーションごとにメモリ空間が独立してしまい、コールバック情報を同一空間内で管理出来ずに困っています。 旧VerのDelphiで16bit DLLなら、interface部に定義した変数、オブジェクトはDLL内で同一空間内で共有出来るようですが、これをDelphi6 32bitDLLで行う事は不可能でしょうか? もしくは、その他の方法で独立メモリ空間を作らないようにする方法はありますでしょうか? 不可能な場合、CreateFileMappingが次に有効な手段として候補に挙がると思います。CreateFileMappingで管理クラスのポインタを渡してクラス共有というのは現実的な手法でしょうか? よろしくお願いいます(..
- ベストアンサー
- その他（プログラミング・開発）
- exeファイルはどのdllを参照すべきか、知っているのでしょうか。
dllとは、プログラムが実行時に参照するものですよね。 よく使われる機能があらかじめ作られているものですよね。 私はＣ言語しか知らないので、Ｃ言語でプログラミングすることで話を進めさせてください。 （とは言っても、ごく初歩的なプログラムが組めるだけの素人です。） ＯＳはWindowsということにします。 Ｃ言語は、関数の集まりでソースが書かれています。 dllも、中身に関数の実体が記述されている、そういうイメージでしょうか。 私がもっと勉強して、複雑なプログラムを組んだりすると、 「あ、これはdllに実体がある機能だから、いちいち実装を書かなくてもいいんだな」 と考えて、ソースファイル（ ～.c ）の中でその関数を使うだろうと思います。 私がよくわからないのはここからです。 dllにある関数をソースで使って、無事コンパイルして、さあリンクしてexeを作りましょう、 というときに、リンカ（リンクを行うプログラム）は、 「そんな関数、実体がないぞ」 って文句を言ってこないのでしょうか。 いや、リンカは、dllに実体がある関数だということを知っているはず。 でもそれって、いちいち 「この関数はどこどこにある ○○.dll というdllに書いてあります」 というふうに、リンカに教えてあげなくてはいけないのでしょうか。 （それってまさか、ソースに書くわけじゃないですよね？ ） それから、 exeファイルっていうのは「この機能はdllに行わせる機能だ」ということを知っているのでしょうか。 dllに行わせる機能だということを知っているとしても、 どのディレクトリにある なんと言う名のdllに その機能が書かれていることまで知っているのでしょうか。 （でもそこまで知っていたら逆に、ディレクトリ構成の違うマシンでは実行できなくなってしまうし。） そういうような原理的なことを教えてください。
- ベストアンサー
- その他（プログラミング・開発）
- Dllの作成について
以下はVC++を使いました。 Dllの関数を扱うプログラムをつくる際に、dllのヘッダとlibを使う場合と、dllのみ必要な時の二種類があります。 どちらも宣言部分のみを先にプログラムに読み込ませて実装部分をプログラム実行時にexeと結びつけるんですよね。 この時どちらもdllが必要なら、上の違いによるメリットやデメリットはなんでしょうか。
- ベストアンサー
- C・C++・C#
- MFC80U.DLLが見つかりません
ある体験版ソフトをアンストールしたら、MFC80U.DLLが指定にのパス内に 見つかりませんとのエラーが出るようになりました。 ネット上の情報から WindowsInstaller-KB893803-v2-x86.exe をダウンロードして、インストールしたんですが状況が変わりません。 どなたか、解決法をご存知ありませんか？
- ベストアンサー
- Windows NT・2000
- DLL登録プログラムに関して
Vistaに対応するためDLLの登録プログラムを自前で作成していますが、登録するDLLによって登録がうまくいかないことがあるので困っています。 regsvr32で登録した場合も同じような現象になります。 具体的には以下のような状況です。 ・レジストリに記憶されるファイルパスが、日本語を含む場合文字化けしてしまいます。 この場合、文字化けしたパスを認識できずアプリケーション側でオブジェクトの生成に失敗してしまいます。 文字化けしないようにするためにはどのようにすればよいでしょうか？ ・また、レジストリに記憶されるファイルパスが短い形式で記憶されます。 フルパスで記憶されるDLLとされないDLLがあるのですが、これはどのよう な違いでしょうか？ 互換性維持のためフルパスで記憶するようにしたいと思っています。 ※DLL自体は私がVC6で作ったものです。 たとえばデスクトップ上にあるDLLをした結果このようになります（作成したDLL) 結果：C:\DOCUME~1\user\デfスXクN~1\regit.dll 期待値：C:\Documents and Settings\user\デスクトップ\regit.dll しかし一方で他のDLLではこのように期待度どおりの結果になります（他のDLL) 結果：C:\Documents and Settings\user\デスクトップ\my.dll 作成したDLLの開発環境は以下のとおりです。 ・Windows XP Home Edition ・Visual C++ 6.0 できればDLLを修正することで解決したいと思っています。 不可能であれば、登録プログラムの方を修正する方向で考えています。 同じ現象に出くわした方がいらっしゃれば、どうかお力添えください。 よろしくお願いします。
- ベストアンサー
- Visual Basic
- regsvr32 Shdocvw.dll で 失敗します
windows Xp SP3 IE6 を使用していて、新しいウインドウが開かなかったり、固まったりするので イベントログをみたら エラー発生アプリケーション iexplore.exe、バージョン 6.0.2900.5512、エラー発生モジュール shdocvw.dll、バージョン 6.0.2900.5512、エラー発生アドレス 0x00034254 と表示されていました。 regsvr32 Shdocvw.dll をファイル名を指定して実行を行うと、 Shdocvw.dll の DllRegisterServer は失敗しました。 戻りコード 0x8002801ｃと表示が出ます。 regsvr32.exe /u Shdocvw.dll は成功します。その後の regsvr32.exe /i Shdocvw.dll は上記同様の失敗表示が発生します。 urlmon.dll Shdocvw.dll Actxprxy.dll Oleaut32.dll Mshtml.dll Browseui.dll Shell32.dllはそれぞれ成功します。 どなたか再インストールなしに復旧する方法をご教授願います。 よろしくお願いします。
- ベストアンサー
- Windows XP
- 抽象クラスとインターフェースの使い分け
抽象クラスとインターフェース、この2つの違い、使い分け方が未だにはっきりとはわかりません・・・ 抽象クラスもインターフェースも実装は持たず、抽象クラスはサブクラスで、インターフェースはそれをインプリメントしたクラスで実装を行うのですよね？ 両者ともに言わば中身はなく外枠だけ定義されていると言えると思うのですが、だとしたらこの2つの違いや使い分けってどうなるのでしょうか。 抽象クラスでは部分的な実装を含められることや、インターフェースでは実装クラスが全てのメソッドを実装しなければいけない、複数実装できるといった使い方の違いしかないのでしょうか。 だとしたら実際に抽象クラスとして用意するのかインターフェースとして用意するのかの選択基準はなんなのでしょうか。 明確にこういう場合は抽象クラス、こういう場合はインターフェースなどと言った使い分けってあるのでしょうか。
- 締切済み
- Java
- x64ネイティブコードのDLLはVBAから呼びだせない？DLLが見つからない？
VC+2005でx64ネイティブコードを出力し、DLLを作成したのですが C:\WindowsフォルダにそのDLLを入れて、いつもどおりVBAから呼びだそうとすると、該当するDLLがありません。と表示されます。 同じように置いているのに無いというメッセージが理解できないです。 x86(32bit)で生成したDLLなら問題なく動作するのですが・・・ 何か違いでもあるのでしょうか？ Declareとかでは呼べないのでしょうか？ ちなみにVBAはExcel2003です。 DLLでなくMFCアプリで完全ネィテイブ.EXEを作らないとx64の環境は生かせないのでしょうか？
- ベストアンサー
- C・C++・C#
- 異なるexeから参照しているdllの変数は実行時のメモリ領域として独立的か？
結論から質問内容を言うと、 異なるexeから参照しているdllの変数は実行時のメモリ領域として独立的か？ 具体的には、 A.exeと、B.exeの両方で参照している Common.dllに定義しているクラスの staticなフィールドは、A.exe実行時のメモリ領域と、 B.exe実行時のメモリ領域と、完全に別で独立状態 であることを前提にしているのですが。。。 これは本当に真なのかを確認させてください。 あたりまえじゃねーかバカ野郎っていわれそうですが ちょっと、そこ間違えると後で、痛いので、 念押しで再確認お願いします。 <質問に至った経緯> Delphi3.0からVB.NET2003(2005未対応のコンポーネントを使用する諸事情があったから) にシステム移行の案件があり、 工数を避けません。現在、開発方針を検討中で調査していると、デルファイプロジェクトＡと、 デルファイプロジェクトＢで、Commonという名前の フォルダにあるソースを共有していて、 A.exeとB.exeを作っていました。 特に共通部分をdllにしていたりしていませんが。 VB.NETでそれは、きついので、 Commonにあるソースだけ、集めたCommon.dllを作る プロジェクトを作り、Ａプロジェクト、ＢプロジェクトがCommon.dllを参照するやり方を検討しました。 Common.dllには、たくさんグローバルな変数が定義されていたので、 グローバルなデータは、もともとのソースファイルごとにクラスを 作ってそこにスタティックなフィールドとして宣言していく。それをAや、Ｂのプロジェクトのソースで 使うが、もともと、デルファイがexeが完全にわかれていたので、VBでdllに分けた結果、実行時にメモリも 共有されると、意図した動きをしてくれない懸念が あるので、それはないのかどうかを確認したかった。 ########################################### 以上です。
- ベストアンサー
- Visual Basic
- 【C#】マネージドDLLによる負荷
１．C#で作成したマネージドDLLを参照し、ImportしてDLL内のクラスを使う方法 ２．DLLにせず、直接ソースを取り込んでひとつのexeファイルとしてしまう方法 １と２ではパフォーマンス的にどちらが有利とかあるでしょうか。 アンマネージドDLLの場合、静的リンクや動的リンクなど、実装によって 多少のパフォーマンス差が出ることがありますが マネージドDLLでも何かパフォーマンス差が発生するのだろうかと ふと疑問に思い質問させていただきました。 私的にはJavaのjarファイルのような扱いと考えている（実行時には展開される）ので DLLにしたことによってパフォーマンス差はあまり出ないと考えているですが あっているでしょうか。 よろしくお願いいたします。
- 締切済み
- C・C++・C#
お礼
う～ん・・・ System.ReflectionのAssemblyオブジェクトによる 限定名での読み込みが近いかもしれません。 私の考えている事はシステムにDLLを登録したいに相当すると思います。