使用现有.NET程序集与命令行工具相同的优缺点

Dan*_*7el 11 .net c# gnupg

我搜索过互联网,似乎无法找到与此主题相关的任何内容.我认为会有一些讨论.我找不到它.

基本上,我正在寻找的是使用现有.NET程序集执行(较旧的)命令行可执行文件所做的相同事情的充分理由.因此,如果我使用了程序集,我会包含它并开始在我的C#代码中使用它.对于我们旧的命令行工具,我会做一个Process.Start(...)等等.

背景是:

我要求对传输到我们系统的文件执行PGP加密和解密.我目前的选择是使用命令行GPG工具(http://www.gnupg.org/)或Bouncy Castle .NET程序集.

有人问我为什么不在我的代码中"自动化"旧的GPG命令行工具.我想用一些情报回答这个问题.现在,我只能想到两个原因:

  1. 错误处理:我应该不仅能够使用.NET程序集获得更好的错误信息,而且可以通过try/catch和异常等更好地处理它们.我甚至可以根据需要滚动我自己的异常,等等.

  2. 代码可移植性:我使用.NET程序集构建的任何内容或多或少都是独立的.我不需要找到GPG可执行文件并将其复制到我复制我使用它编写的应用程序的每个地方.

  3. 表现:可能.我没有任何关于此的经验或数据.

我很感激有关这个主题的任何意见.

Dav*_*ter 6

老实说,我会选择.NET程序集,因为它似乎是一个更简单的解决方案,也是一个比启动新流程更紧凑的解决方案.我觉得这种方式的一些原因如下:

  1. 使用命令行工具,您将启动一个新进程.因此,它是一个完全独立的进程ID,它将在现有应用程序的作用域和应用程序域之外运行.应用程序和进程之间的所有通信都将跨越进程边界,并且必须通过服务调用,某种共享内存或其他方法来完成,这可能很麻烦(特别是在处理问题时).
  2. 启动新流程后,您基本上无法从应用程序中控制该流程.如果您的应用程序死亡或关闭,您将不得不明确地终止该进程 - 否则您可能会将句柄保持打开状态,文件已锁定等.
  3. 在应用程序中包含.NET程序集允许所有内容在相同的上下文中运行(通常),这样可以在组件之间实现更好的通信,更容易调试和解决问题(通常),以及管理单个进程.
  4. 您可以更好地控制代码.启动一个进程基本上是一个黑盒子 - 你不知道它内部发生了什么.当然,使用.NET程序集你也有类似的黑盒方案,但由于它在同一个过程中,你可能会对如何进行调用,抛出异常等等有一些额外的了解.基本上,你使用.NET程序集更深入地了解组件,而不是启动新进程.

这些只是我头脑中的一些想法.我希望这有帮助.如果您有任何疑问,请告诉我,我会详细说明我的答案.祝好运!!