2013-01-24 2 views
7

私たちのチームでは、外部の第三者コードを呼び出して、C#コードの出力を処理する必要があります。どのアプローチが良いですか:Process.StartまたはDLLを直接呼び出しますか?

第三者コードは、dllと、exeというファイルの2種類があります(これらはおそらくdllと呼ばれています)。また、可能なアプローチは、Process.Startステートメントを使用して実行可能ファイルを実行し、その出力をキャッチすることです。もう1つはdllに直接電話することです。

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

実行可能ファイルを呼び出すことは簡単ですが、もう一方では堅牢ではありません。一方

dllを呼び出すと仕事をするために、より適切な方法に見えますが、他に - 我々がネイティブCコードを持っているすべての関数の結合C#を提供するために、本当に複雑な作業かもしれません。

しかし、私は最終的な決定を下すために、このトピックについてより詳細な分析が必要です。誰かが前に同じ質問に直面したことがありますか、おそらくあなたの発見を分かち合うことができます。

非常に便利です!

EDIT:この特定のケースでは、ビデオの変換について話しています。私は、ユーザーからビデオストリームを取得し、すべてのための1つのビデオ形式に変換する必要があります。 ffmpegに電話をかけて、何かがうまくいかなくなるまですべてがOKで、エンコードを再開するか、何らかのアクションを取る必要があります。どのくらいの時間がかかるか見積もることができず、いくつかのビデオを並行して変換する必要がある場合は、ffmpegはそれほど柔軟性がありません。

少なくとも私は今それを見ています。

+1

多くの詳細を提供する必要があります。何を試しましたか?何かテストしましたか? COMやUSB /ドライバ、パーミッションなどの依存関係はありますか?不安定さはありますか?どのレベルの制御/細分性/パフォーマンスが必要ですか? – Yahia

答えて

4

いくつかの注意事項があります。

  1. あなたはDLLのソースを持っていますか?
  2. これらのdllをどのくらい呼び出すつもりですか?
  3. dllのAPIと使用方法はどれくらい複雑ですか?

回答によっては、

場合のバインディングを作成します:あなたが頻繁にDLLを呼び出します

  • 。ダイレクトコールははるかに高速です。
  • ソースがあり、どれくらい良いかを確認しています。それ以外の場合、メモリリーク、呼び出し規約などの大きな問題が発生する可能性があります。
  • dllのAPIはあまりにも複雑ではないので、C++オブジェクトなどを送る必要はありません。

利用の実行可能ファイル:

  • あなたはたまにしかそれらを実行する必要がある場合。別のプロセスの作成のオーバーヘッドはあなたにとって重要ではありません。
  • コードの品質がわからない場合は、あなたのコードにとっては、はるかに安全で堅牢で、不正に実装されたDLLを読み込むことはありません。問題が発生した場合は、いつでも.exeを何度も実行しようとすることができます。しかし、それはあなたのアプリをクラッシュdll、あなたは何もすることはできません。
  • APIが非常に複雑で、exeに多くの機能がある場合は、再実装する必要があります。
+0

この答えに追加するだけでなく、実行可能ファイルの起動時間も考慮してください。状態&cを維持するプログラムの場合すべての通話の開始コストを支払うことは望ましくない可能性があります。 –

0

これは、ライブラリからのapiサポートの観点からコードがどれほど細かいことを期待しているかによって決まります。

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

また、これはネイティブCコードであるため、DLL参照を追加するとアンマネージコードを処理する必要があります。これは、私にとってオプションがない限り個人的には行かないことです。

0

dllがうまく書かれていて、メモリリークがない場合は、dllを使用するほうが、新しいプロセスの作成にかかるオーバーヘッドを必要としないため、dllを使用する方が効果的です。

0

あなたの要件、時間枠、exeファイルの出力がどれくらい安定しているか、どのくらい簡単に解析できるか、ということです。どちらの方法も可能です。

たとえば、Mercurialはコンソール出力を、Pythonコードを直接使用することができますが、それと対話するための主要な方法と見なします。

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

0

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

DLL は直接 機能ごとのエントリポイントが システムは、既存のスレッドのコンテキストにDLLをロードしている関数呼び出しによって、あなたに多くの柔軟性を提供します

ので、DLLは、計算リソースのためにはるかに優れて呼び出し、および提供もっとフレキシビリティ。管理されたコードとアンマネージのコードからDLLを呼び出すことができることを考慮して、C#からマネージドDLLとアンマネージドDLLを呼び出すことができます。

DLLにはインターフェイスがあり、直接参照を追加できます。簡単な言葉で

[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をインポートし、

0

回答は、外部アプリケーションがDLLを:

    ます使用する方法に依存してマーシャリングを使用して.NET型にパラメータをマッピングするようにそれを呼び出すために
  • 複数のdll関数を複数回呼び出してそのビジネスプロセスが大きく複雑になる場合、exeを呼び出します.C#コードですべてのexeロジックを再実装したくない場合。
  • exeがdllから1,2個の関数しか呼び出せない場合は、dllを直接呼び出します。呼び出し順序とパラメータは、よく知られているか、まったく存在しません。

私は一般的に、新しいプロセスの作成とその出力の処理に伴うオーバーヘッドや問題の可能性があるため、dllを直接呼び出すことをお勧めします。ネイティブコードを恐れないでください。もしdll関数がシンプルならば、PInvokeで簡単にそれらの関数を呼び出すことができます。

関連する問題