我搜索过互联网，似乎无法找到与此主题相关的任何内容。我认为会有一些讨论。我找不到它。
基本上，我正在寻找的是使用现有.NET程序集执行（较旧的）命令行可执行文件所能完成的相同操作的充分理由。因此，如果我使用了程序集，我会包含它并开始在我的C＃代码中使用它。对于我们旧的命令行工具，我会做一个 Process.Start(...) 等等。
背景是：
我要求对传输到我们系统的文件执行PGP加密和解密。我目前的选择是使用命令行GPG工具（http://www.gnupg.org/）或Bouncy Castle .NET程序集。
有人问我为什么不在我的代码中“自动化”旧的GPG命令行工具。我想用一些情报回答这个问题。现在，我只能想到两个原因：
错误处理：我应该不仅能够使用.NET程序集获得更好的错误信息，而且可以通过try / catch异常等处理它们。我甚至可以根据需要滚动自己的异常等。
代码可移植性：我使用.NET程序集构建的任何内容或多或少都是独立的。我不需要找到GPG可执行文件并将其复制到我复制我使用它编写的应用程序的每个地方。
表现：可能。我没有任何关于此的经验或数据。
我很感激有关此主题的任何意见。
老实说，我会选择.NET程序集，因为它似乎是一个更简单的解决方案，也是一个比启动新流程更紧密的解决方案。我觉得这种方式的一些原因如下：
- 使用命令行工具，您将启动一个新进程。因此，它是一个完全独立的进程ID，并且将在现有应用程序的范围和应用程序域之外运行。应用程序和进程之间的所有通信都将跨越进程边界，并且必须通过服务调用，某种共享内存或其他方法来完成，这可能很麻烦（特别是在处理问题时）。
- 启动新流程后，您基本上无法从应用程序中控制该流程。如果您的应用程序死亡或关闭，您将不得不明确地终止该进程 - 否则您可能会将句柄保持打开状态，文件被锁定等。
- 在应用程序中包含.NET程序集允许所有内容在相同的上下文中运行（通常），这样可以实现组件之间更好的通信，更容易调试和故障排除（通常），以及管理单个进程。
- 您可以更好地控制代码。启动一个进程基本上是一个黑盒子 - 你不知道它内部发生了什么。当然，使用.NET程序集你也有类似的黑盒方案，但由于它在同一个过程中，你可能会对如何进行调用，抛出异常等等有一些额外的了解。基本上，你使用.NET程序集更深入地了解组件，而不是启动新进程。
这些只是我头脑中的一些想法。我希望这有帮助。如果您有任何疑问，请告诉我，我会详细说明我的答案。祝你好运！！
我个人会尽可能使用.Net程序集而不是命令行工具。
优点：
- 更容易部署（您不必复制可执行文件）
- 更好的可移植性（取决于命令行工具编译选项，它不能在某些平台上工作;另一方面，编译为目标AnyCPU的纯.Net托管程序集应该在x86 / x64机器上正常工作）
- 更容易操作第三方库（函数参数与命令行解析/格式化）
- 选择是否同步调用您的方法;另一方面，单独的进程必须是异步的。线程/进程同步不是一项简单的工作。
- 你不必处理 IPC 因为一切都在一个过程中
- 更容易调试（逐步调试......等）
- 异常管理也更容易（您将获得完整的堆栈跟踪，而不仅仅是虚拟进程退出代码）
- 使用.Net概念（面向对象编程，
Exceptions， events...等等。）
我同意1,2和3.为每个加密/解密启动一个新进程肯定比在进程中执行它更昂贵。如果您需要同时执行多个加密/解密，这将变得更加重要，这将阅读您希望您做的问题。
另外，是否有64位版本的命令行工具？这可能是反对的论点。
它更简单。你的三个项目中的两个都回到了这个。
第三种情况可能是正确的，因为流程较少而且不需要在它们之间进行通信，或者是错误的，因为可执行程序恰好提供了比程序集更好的性能，并且超出了这种效果。
但简单购买了很多东西，它继续给予（你可能必须支持这个应用程序一段时间）。也许还有很多其他的“专业人士”可以被认为最终归结为此。
真的，当事情变得更简单（而且非常简单，而不是过度简单的警报调用，从长远来看会变得更复杂），你需要一些 真 引人注目的反驳论点超越了这一点。