出于相同目的，使用现有 .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 程序集而不是命令行工具。

优点：

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

Answer 3

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

另外，有64位版本的命令行工具吗？这可能会遭到反对。

Answer 4

做起来比较简单。你的三件物品中的两件都回到了这一点。

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

但简单性会带来很多好处，并且它会不断给予（您可能需要支持这个应用程序一段时间）。可能还有其他一些可以想到的“优点”最终归结为这一点。

确实，当某件事变得更简单（而且确实更简单，而不是过度简单的诱惑，从长远来看最终会变得更加复杂）时，你需要一些真正令人信服的反驳论点来权衡这一点。