0

サードパーティのWindowsアプリケーションによって呼び出されるカスタムdllをいくつか開発しました。これらのdllは、必要に応じてロード/アンロードされます。

ほとんどのdllはWebサービスを呼び出し、これらにはURL、タイムアウトなどを構成する必要があります。

dllは永続的にメモリに存在しないため、呼び出されるたびに構成を読み取る必要があります。これは私には最適ではないようです。

これを処理するためのより良い方法はありますか？

注：IT部門が必要に応じて変更できるように、構成可能な情報はxmlファイルに含まれています。レジストリの編集は受け付けません。

注：これらのdllは、多くのサードパーティアプリケーションに対応しており、基本的に外部EDMSインターフェイスを実装しています。ベンダーは、必要なパラメーターの受け渡しを受け入れません。

注：これはa.NETアプリケーションであり、dllはC＃で記述されています。基本的に、ある種のEDMS操作を実行する必要があるときにこのdllにアクセスするシック（Windowsアプリケーション）クライアントとシンクライアントの両方があります。EDMSインターフェイスは、dllに実装する必要のある一連の呼び出しとして定義され、dllはEDMS機能の実装方法を決定します。たとえば、一部のクライアントでは、「ドキュメントの登録」によってDBが更新され、他のクライアントでは、同じ呼び出しでサードパーティのEDMSシステム。ASPクライアントはありません。

私の理解では、dllはクライアントがEDMS操作にアクセスするときにロードされ、呼び出しが終了するとアンロードされます。クライアントは、しばらくの間（場合によっては1時間以上）別のEDMS操作を実行する必要がない場合があります。

4

7 に答える 7

1

もっと情報を提供する必要があると思います。構成情報を永続化するには、非常に多くのアプローチがあります。開発プラットフォームすら知りません。。ネット？

  1. レジストリが常に利用可能であることが確実でない限り、レジストリに依存することはありません。クライアントマシンでそれを回避できるかもしれませんが、Webサービスについてはすでに説明しました。

  2. 現在のディレクトリにあるXMLファイルは、サーバー側のサードパーティのdllで非常に人気があるようです。ただし、これらの構成はオプションです。

  3. これがASPの場合、構成の永続化方法を選択する際に信頼レベルが非常に重要になります。

  4. アプリケーションサーバーの「アプリケーションスコープ」を使用できる場合があります。これは、アプリケーションの存続期間ごとに1回ロードされます。DLLは、必要性も検出した場合、そのデータを無効にすることができます。

  5. テキストファイル、XMLファイル、データベース、共有メモリセグメントなどのさまざまなIPC、アプリケーションスコープを使用して、構成情報を保持しました。それはあなたのプロジェクトの詳細に大きく依存します。

さらに詳しく説明しますか？

編集。あなたの説明を考慮して、私はXMLファイルを使用します。このカスタムXMLファイルは、事前定義および文書化された検索パスを使用してロードされます。これがASP.Netの場合、たとえばServer.MapPath（）を使用して、App_Dataなどのさまざまなフォルダーを確認できます。ただし、DLLは最初に構成ファイルの現在のディレクトリをチェックします。次に、構成データを保持し、それを必要とするすべての子スレッドに渡す「マネージャー」スレッドを使用できます。共有では、共有メモリセグメントのようにIPCを使用できます。

これは面倒なようですが、情報を何らかのスコープに保存する必要があります...ディスク、メモリ（アプリケーションスコープ、セッションスコープ、DLLグローバルスコープ、別のプロセス/ IPCなど）のいずれかから

ASP.Netには、web.configなどの標準構成ファイルにカスタム構成セクションを追加する機能もあります。これらのセクションには自由にアクセスでき、DLLがいつロードされたかには依存しません。

DLLがメモリから削除されていると思うのはなぜですか？

于 2008-09-25T23:50:20.747 に答える
1

レジストリを使用して構成情報を保存します。間違いなく十分に高速です。

于 2008-09-25T23:40:36.137 に答える
0

dllはどのくらいの頻度でアンロードされますか？COM dllは、DllCanUnloadメソッドを介してアンロードされるタイミングを制御できます。これらがCOMコンポーネントである場合は、頻繁なロードとアンロードを防ぐために、ここで何らかのタイムアウトを実装することを検討できます。dllがかなりの頻度で構成をリロードしない限り、実際のパフォーマンスのボトルネックになる可能性はほとんどありません。

dllが特定の時点で構成を再ロードすることを知っていると、構成を有効にするためにユーザーがホストプロセスを再起動したり、マシンを再起動したりする必要があるかどうか疑問に思うのを防ぐことができるため、便利な機能です。ファイルを監視して変更を確認し、最新の状態に保つこともできます。

于 2008-09-25T23:50:59.903 に答える
0

DLLが構成情報を取得するための最良の方法は、それを使用しているアプリケーションを介することだと思います-Nilsが提案したように暗黙の「Init」呼び出しを介するか、構成ファイルを介します。

DLL は通常、どのコンテキストで使用されるかを確認できないため、「自分自身を構成する」べきではありません。ユーザー (アプリケーションなど) が異なれば、作成する構成設定も異なる場合があります。

アプリケーションは .NET で記述されているとおっしゃっていたので、DLL の機能に必要な構成を構成ファイル ("whatever.exe.config") に配置し、AppSettings を介して DLL からアクセスすることを単に要求する必要があります。カスタム構成セクションを介して改善します。

さらに、可能な場合は設定に適切なデフォルト値を提供することをお勧めします (ただし、ネットワーク アドレスの場合はおそらくそうではありません)。

于 2008-09-26T04:40:46.367 に答える
0

dll が 1 時間ごとにメモリからロードおよびアンロードされる場合、mslal の初期化 (ファイル/レジストリの読み取り) による非効率性は無視できます。

ただし、これがより頻繁に行われる場合、DLL のロードとアンロードの物理的な動作が非効率になります。これは、小さな初期化よりも効率が悪い可能性があります。

したがって、それらをメモリに固定しておく方がよい場合があります。そうすれば、ロード時に実行される初期化が繰り返されず、ロードとアンロードの非効率性も回避できます。この方法で 2 つの問題を解決します。

C++ でこれを行う方法を教えてください。C# でこれを行う方法がわからない。GetModuleHandle + このハンドルで LoadLibrary 呼び出しを追加することは、C++ でこれを行う方法です。

于 2008-09-26T04:48:32.557 に答える
0

呼び出し元のアプリケーションに、必要なものをデータ構造に入力させてみませんか? init-call などの一部として実行できます。

于 2008-09-25T23:41:56.790 に答える
0

これを行う 1 つの方法は、必要な設定を指定する DLL にインターフェイスを含めることです。

次に、このインターフェイスを実装するクラスを作成し、開始時に DLL に渡すのは「アプリケーション プロジェクト」次第です。これにより、プロジェクトに応じて実装を自由に変更できます。1 つは web.config から読み取り、もう 1 つは DB から読み取ります。

于 2012-01-23T12:02:25.997 に答える