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

Question

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

基本上，我正在寻找的是使用现有.NET程序集执行（较旧的）命令行可执行文件所能完成的相同操作的充分理由。因此，如果我使用了程序集，我会包含它并开始在我的C＃代码中使用它。对于我们旧的命令行工具，我会做Process.Start(...)等等。

背景是：

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

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

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

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

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

我很感激有关此主题的任何意见。

Answer 1

老实说，我会使用.NET程序集，因为它似乎是一个比启动新进程更简单的解决方案和更紧凑的解决方案。我觉得这种方式的一些原因如下：

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

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

Answer 2

我个人会尽可能使用.Net程序集而不是命令行工具。

优点：

• 更易于部署（您不必复制可执行文件）
• 更好的可移植性（取决于命令行工具编译选项，它在某些平台上无法工作;另一方面，编译为目标AnyCPU的纯.Net托管程序集应该可以在x86 / x64机器上正常工作）
• 更容易操作第三方库（函数参数与命令行解析/格式化）
• 选择是否同步调用您的方法;另一方面，单独的进程必须是异步的。线程/进程同步不是一项微不足道的工作。
• 您不必处理IPC，因为一切都在一个过程中
• 更容易调试（逐步调试......等）
• 异常管理也更容易（您将获得完整的堆栈跟踪，而不仅仅是虚拟进程退出代码）
• .Net概念的使用（面向对象编程，Exceptions，events等等。）

Answer 3

我同意1,2和3.为每个加密/解密启动一个新进程肯定比在进程中执行它更昂贵。如果您需要同时执行多个加密/解密，这将变得更加重要，这将阅读您期望的问题。

另外，是否有64位版本的命令行工具？这可能是反对的论据。

Answer 4

这样做更简单。你的三个项目中的两个都回到了这个。

第三种情况可能是正确的，因为流程较少，不需要在它们之间进行通信，或者是错误的，因为可执行文件恰好提供了比程序集更好的性能，并且超出了这种效果。

但简单购买了很多东西，而且它一直在给予（你可能必须支持这个应用程序一段时间）。可能有一些其他“专业人士”可以被认为最终归结为此。

真的，当事情变得更简单（而且非常简单，而不是过度简单的警报调用，从长远来看会变得更加复杂），你需要一些真的引人注目反驳这一点的反驳论点。