7

私たちのチームでは、外部のサード パーティ コードを呼び出して、C# コードからの出力を処理する必要があるという選択に直面しました。

サードパーティのコードは 2 つの形式で利用可能です:dllのセットと単一のexeファイル (おそらくこれらの を単独で呼び出していますdll)。考えられるアプローチは次のとおりです。Process.Startステートメントを使用して実行可能ファイルを実行し、その出力をキャッチします。もう一つは、dll直接電話することです。

どのアプローチを使用すべきかを理解しようとしています。

実行可能ファイルの呼び出しは単純ですが、堅牢ではありません。

呼び出しは、ジョブを実行するためのより適切な方法のように見えますが、ネイティブコードに含まれるすべての関数にバインドdllを提供するのは、非常に複雑なタスクになる可能性があります。C#C

しかし、最終決定を下すには、このトピックに関するより実質的な分析が必要です。以前に同じ質問に直面した人はいますか?あなたの発見を共有できるかもしれません.

それは非常に便利です！

編集：この特定のケースでのビデオ変換について話しています。ユーザーからビデオ ストリームを取得し、それを 1 つのビデオ形式に変換する必要があります。仕事をするために電話をかけることは可能でffmpegあり、何かがうまくいかず、エンコーディングを再開するか、何らかの措置を講じる必要があるまで、すべて問題ありません. どれくらいの時間がかかるかを見積もることができませんでした.複数のビデオを並行して変換する必要がある場合、ffmpeg私が計画しているように、それほど柔軟ではありません...

少なくとも私が今見ているように。掘り下げていくと、さらに多くの問題が発生する可能性があります。

4

6 に答える 6

4

いくつかの考慮事項があります。

  1. dll のソースはありますか?
  2. それらのdllをどれだけ呼び出すつもりですか？
  3. dll の API はどのくらい複雑ですか?また、あなたの使い方は?

答え次第。

次の場合にバインディングを作成します。

  • dll を頻繁に呼び出します。直接呼び出しの方がはるかに高速です。
  • ソースがあり、それらがどれほど優れているかを確認してください。そうしないと、メモリリーク、呼び出し規約などで大きな問題が発生する可能性があります。
  • dll の API はそれほど複雑ではないため、C++ オブジェクトなどをそれらに送信する必要はありません。または、exe で既に行われている多くの作業を実装します。

実行可能ファイルを使用します。

  • たまにしか実行する必要がない場合。別のプロセスを作成するオーバーヘッドは問題になりません。
  • コードの品質がわからない場合。不適切に実装された dll をロードしない方が、コードにとってはるかに安全で堅牢になります。問題が発生した場合は、いつでも .exe を数回実行することができます。しかし、dll がアプリをクラッシュさせると、何もできなくなります。
  • API が非常に複雑で、exe に多くの機能がある場合は、再実装する必要があります。
于 2013-01-24T11:37:21.153 に答える
0

答えは、外部アプリケーションが dll を使用する方法によって異なります。

  • 複数の dll 関数を複数回呼び出し、そのビジネス プロセスが大きくて複雑な場合は、exe を呼び出します。C# コードですべての exe ロジックを再実装する必要はありません。
  • dll を直接呼び出します。exe が dll から 1 つまたは 2 つの関数のみを呼び出す場合、呼び出し順序とパラメーターはよく知られているか、まったくありません。

私は一般的に、dll を直接呼び出すことを好みます。これにより、多くのオーバーヘッドと、新しいプロセスの生成とその出力の処理に関する潜在的な問題が取り除かれるためです。また、ネイティブ コードを恐れないでください。dll 関数が単純であれば、PInvoke を使用すると、これらの関数を簡単に呼び出すことができます。

于 2013-01-24T11:33:22.363 に答える
0

EXE 呼び出されるメイン エントリは 1 つだけなので、関数を直接呼び出すことはできません。exeを呼び出すと、新しいプロセスが作成され、そのプロセスのメインスレッドのコンテキストでエントリスレッドが呼び出されます。

DLL 関数を直接呼び出すことで柔軟性が向上 関数ごとにエントリ ポイントが存在 システムが既存のスレッドのコンテキストに DLL をロード

そのため、DLL の呼び出しは計算リソースにとってはるかに優れており、柔軟性が向上します。マネージド コードとアンマネージド コードから DLL を呼び出すことができ、C# からマネージド DLL とアンマネージド DLL を呼び出すことができることを考慮してください。

DLL に come インターフェイスがある場合は、refrence を直接追加できます。ない場合でも、以下のように呼び出すことができます

 [DllImport(@"TestLib.dll")]
    public static extern void InitParam([MarshalAs(UnmanagedType.LPWStr)] string inputFile,
        [MarshalAs(UnmanagedType.LPWStr)] string outputFile,
        [MarshalAs(UnmanagedType.LPWStr)] string templateFile,
        [MarshalAs(UnmanagedType.LPWStr)] string userName,
        [MarshalAs(UnmanagedType.LPWStr)] string manifestFilePath,
        [MarshalAs(UnmanagedType.LPWStr)] string usersRightList);

簡単に言えば、DLL をインポートし、マーシャリングを使用してパラメーターを .net 型にマップします。

于 2013-01-24T11:31:17.120 に答える
0

exeそれはすべて、要件、時間枠、ファイルの出力の安定性、および解析の容易さに依存すると思います。どちらの方法も実行可能です。

たとえば、Mercurial は、Python コードを直接使用することもできますが、コンソール出力が主要な操作方法であると考えています。

一方、C# から C 関数を呼び出すのはかなり簡単なので、これもオプションになる可能性があります。ただし、何百もの C 関数をマップする必要がある場合は、そうする時間があるかどうかを自問する必要があります。

于 2013-01-24T11:30:43.863 に答える
0

これは、ライブラリからの API サポートに関して、コードがどの程度の粒度を期待するかに依存すると思います。

実行可能ファイルにワークフローが十分にカプセル化されている場合は、実行可能ファイルを簡単に呼び出すことができるという利点があります。

また、これはネイティブ C コードであると述べているため、DLL 参照を追加することは、アンマネージ コードを処理する必要があることを意味します。

于 2013-01-24T11:28:15.913 に答える
0

dll が適切に作成されていて、メモリ リークがない場合は、新しいプロセス作成のオーバーヘッドが必要ないため、dll を使用することをお勧めします。

于 2013-01-24T11:29:32.360 に答える