哪种方法更好：Process.Start或直接调用DLL？

 

在我们的团队中，我们面临着选择：我们需要调用外部第三方代码并处理来自C＃代码的输出。

第三方代码有两种形式：一组dll和单个exe文件（可能自己调用​​这些dll ）。 可能的方法可能是：使用Process.Start语句来运行可执行文件并捕获其输出。 另一个是直接调用dll 。

我试图理解我们应该使用哪种方法。

一方面调用可执行文件很简单，但另一方面 - 它感觉不健壮。

一方面，调用dll看起来更加正确，但另一方面，为本机C代码中的所有函数提供C#绑定可能非常复杂。

但我需要对此主题进行更实质性的分析才能做出最终决定。 以前有没有人面对同样的问题，也许你可以分享你的发现。

这将是非常有用的！

编辑 ：我在说这个特殊情况下的视频转换。 我需要从用户获取视频流并将其转换为所有视频格式。 可以调用ffmpeg来完成这项工作，并且一切正常，直到出现问题，我需要重新启动编码或采取任何行动。 我无法估计需要多长时间，如果我需要同时转换多个视频， ffmpeg将不会那么灵活，因为我计划它是......

至少现在我看到了。 当我深入挖掘时，可能会出现更多问题。

有几个考虑因素：

  • 你有没有dll的源代码？
  • 你打算称这些DLL多少钱？
  • DLL的API和你的使用有多复杂？

    • 根据答案。

    创建绑定如果：

  • 你会经常打电话给dlls。 直接呼叫要快得多。
  • 你有源并检查它们有多好。 否则，你可能会遇到内存泄漏，调用约定等问题。
  • dll的API不是太复杂，所以你不需要发送C ++对象给他们，等等。或者说exe已经在exe中做了很多工作。

    • 使用可执行文件：

  • 如果你只需要偶尔运行它们。 创建另一个流程的开销对你无关紧要。
  • 如果您不确定代码的质量。 它对你的代码来说更安全和健壮，而不是加载一些执行得不好的dll。 如果发生问题，您可以尝试多次运行.exe。 但它会崩溃你的应用程序，你什么都做不了。
  • 如果API非常复杂，并且exe有很多功能，那么您将不得不重新实现。

    • 我想说这取决于你的代码在图书馆的api支持方面会有多大的粒度。

    如果可执行文件将工作流程封装得足够好，则可以从调用可执行文件的简单性中受益。

    此外，由于您提到这是本地C代码，因此添加DLL引用意味着必须处理非托管代码，除非没有我的选择，否则我个人不会这样做。

    如果dll编写得很好，并且没有内存泄漏，那么最好使用dll，因为它不需要新的进程创建开销。

    链接地址: http://www.djcxy.com/p/68911.html

    上一篇: Which approach better: Process.Start or call DLL directly?

    下一篇: Is there a Way to localize an Application on Various Platforms