c# - 在 C# 项目中引用 exe 文件是一种不好的做法吗

Question

我有一个简单的问题。

我知道我可以在我的 C# 项目中引用一个 .net 可执行文件。

我不想用“输出类型:Windows 应用程序”制作不必要的项目，只是为了调用一些 dll。

我只是想知道引用 exe 文件是可以的还是不好的做法？

Answer 1

是的，由于以下原因，这可以被视为一种不好的做法:

糟糕的项目架构
如果您需要从 .exe 调用某些逻辑，则该逻辑被错误地放置在那里。相反，您应该将它放在一个单独的 dll 中，并从您当前引用的可执行文件和引用该可执行文件的应用程序中引用相同的 .dll。
正如 comments below 中所建议的，将逻辑提取到库中可以帮助您避免一些 CPU 架构限制，我将在下一点中描述这些限制，因为可以构建库以针对任何 CPU。

架构限制
引用的可执行文件可能已构建为以最佳方式处理 32 位或 64 位机器，甚至特定 CPU(如 Itanium)。可以在没有这些规范的情况下构建一个库，以便跨 CPU 兼容，从而被以后的任何项目引用。如果您引用具有特定体系结构设置的可执行文件，则应使用与引用项目兼容的设置。我认为这是一个限制，因为您无法将最终产品分发到某些平台。

使单元测试变得困难 .
正如阿贝尔暗示的那样in the comments ，您的单元测试将进入他们自己的 DLL，他们也需要引用可执行文件。如果您不使用 InternalsVisibleTo 公开某些内部方法/字段，则可能很难对其进行测试。属性，或使用反射(这是较慢的替代方法)来检查和断言对象的某些非公开可见状态。可执行文件可能无法使用 InternalsVisibleTo 构建属性集，如果您回退到反射，您可能会遇到 .NET 安全问题，阻止您反射(reflect)可执行文件的成员(例如，因为测试套件是在更严格的设置中执行的)。

您还将遇到上述架构限制，这将导致您的单元测试使用相同的架构。如果您的测试套件作为自动构建的一部分在远程机器上执行(例如在 TravisCI、Bamboo、TeamCity 等中)，则可能会出现问题。然后 CI 代理必须符合可执行文件和测试套件的 CPU 架构。如果没有合适的代理，则无法运行测试。此外，如果您使用公共(public) CI 平台来构建应用程序和执行测试，这可以算作法律意义上的可执行文件的分发。您很可能会违反可执行文件的许可证——有关更多详细信息，请参阅下一节。

潜在的许可问题
您应该小心地分发您的应用程序。如果引用的可执行文件需要额外的许可或费用才能使用，您将必须强制用户接受该可执行文件的许可以及您的应用程序之一(并在需要时支付费用)，否则您将面临非法分发的风险它与您的软件。这也意味着 你有权利首先引用可执行文件。

未知后果
可执行文件将复制到 bin 文件夹中，并与您的应用程序一起安装。不知道如果有人浏览 bin 文件夹并执行它会发生什么。这有几个问题:

由于不正确的输入，可执行文件崩溃或行为不端。如果它没有任何 GUI，通常会发生这种情况(例如，如果用户双击命令行程序，它将不会以命令行参数的形式获得任何输入，从而导致崩溃或行为不端)。

可执行文件不打算由您的程序所有者使用，因为这在法律或逻辑上与您的软件的功能相矛盾。

然而，在某些情况下引用可执行文件是合理的，但这种情况很少见:

可执行文件来自 第三方 ，并且不存在具有相同功能的库，并且没有其他方法可以链接到该功能。它也可能是您的雇主或客户对您的项目的明确要求。

可执行文件是 用另一种语言写的 并且您需要通过互操作与它进行通信。

只要后者不适用于您，特别是如果您开发自己引用的可执行文件，我肯定会建议将所需的逻辑提取到单独的库中。

1 事实上，正如 Dominic Kexel's comment 所提到的，您还可以构建一个针对任何 CPU 的可执行文件。 .相反也是可能的 - 为特定的 CPU 构建一个库，但不太常见，因为可执行文件通常是针对硬件定制的。
因此，为了澄清我的观点，我想到了引用第 3 方可执行文件，或者由于其他原因无法重建的可执行文件，并且该可执行文件已经针对某些特定架构进行了优化。如果您 可以 重建并更改可执行文件的 objective-c PU，然后您绝对可以将所需的逻辑提取到 dll 中。