使用.dll文件比将.cs文件链接到项目(对于我自己的泛型助手类/扩展方法)的优点

Question

我有一个帮助项目，在我创建的所有应用程序中都使用它。它包含了一些扩展方法和一些通用的助手类、控件等等。我不时地更新/扩展助手项目。这些通常是小的，不相关的项目，我是唯一的工作人员，所有这些。

我尝试了两种方法来使用它

• 将.cs文件直接添加到我使用它们的每个项目中(添加为链接)
• 将其编译为.dll并将其添加为参考

我看到了这些方法的一些优点和缺点。

第一项：

• 更简单，因为助手类被编译到exe文件中，因此我通常可以很容易地提供一个工作正常的.exe文件。因为我添加了链接，所以我可以非常肯定，每当我构建使用该助手的任何项目时，助手文件都将是最新版本。
• 更为简单，因为我可以分离文件，以便可以单独引用在.NET 4.0上运行良好的扩展名方法和需要.NET 4.5的方法，这意味着整个应用程序都可以在.NET 4.0上运行。
• 允许通过代码进行调试，具有断点等所有优点等.
• 似乎不是“最佳实践”

第二项：

• 这似乎是正确的做法，但：
• 要求我提供一个单独的.dll文件，由于某些原因，用户更难使用这个文件(他们倾向于在没有.dll的情况下共享我的程序，而后者在启动时崩溃)
• 当它被编译成单个.dll时，它将需要最高版本的.NET --我的许多用户没有.NET 4.5，只有我的助手类的一些元素需要这一点，这意味着我可以无缘无故地强迫一些人更新他们的系统。
• 我还需要确保每当我更新我的任何程序时，我都会交付.dll文件--尽管我不知道它是否在上一个版本之后被修改过，或者没有(可能是，但也可以是相同的版本)。我看不出一种简单的方法来确定这一点，如果不跟踪程序集版本，这是额外的工作。现在，当我更新我的程序时，我只提供更新的exe，并且我喜欢保持它的小和低概要。

那么，在这里使用.dll文件的实际好处是什么？请注意，我是所有应用程序和助手文件中唯一一个编辑代码的人。

另外，为了澄清，应用程序通常很少，而助手类中包含的代码对所有应用程序都是完全通用的(一些简单的字符串比较、路径或XML操作等等)。

事实上，刚才有人让我意识到还有第三种选择。由于我在一个单独的项目中有帮助代码，我可以将这个项目添加到我的每个单独应用程序的解决方案中--这有点像单个文件的'Add‘，除了我只添加一个项目.但是正如布朗博士所注意到的，这实际上意味着.dll将需要添加到项目中。

还有一点是赞成不使用dll文件的，那就是能够通过helper类主动地进行调试.

Answer 1

你已经发现了大部分的利弊。使用cs文件作为引用确实更轻量级，而且通常更易于管理。但是，当您的cs文件是完全独立的并且没有任何特殊的构建需求时，我建议只使用这种方法。

使用单独的DLL

• 将使对其他实用程序或库的依赖显式(因此，只要您没有这种依赖关系，它将工作良好)
• 将允许您定义特定的构建配置(例如，如果一个类仅在x86配置中工作，或者至少需要.NET 4.0，则程序集的构建配置使此需求变得显式)。

因此，特别是如果您有大量的单类自包含组件，使用对文件的引用是很好的，但是如果有引用其他组件的组件，或者特定的构建需求，我建议使用DLL。

为了减轻管理许多独立DLL的问题，您可以创建一个安装程序包，或者利用ILMerge，它可以将一组程序集嵌入到单个可执行文件中。在我们的环境中，通过为每个应用程序使用一个部署脚本，我们以不同的方式处理这个问题。此脚本确保在发布新的应用程序发行版时始终将所有所需的all传递给生产部门。

Answer 2

当应用程序很大且有需要更新的部分时，DLLs是很方便的，而不是整个应用程序。因此，如果您正在编写MS Word，可以方便地在DLL中使用拼写检查代码，而无需更新MS Word的全部内容。如果您正在编写的是一个小型实用程序(或者一系列自成一体的应用程序，它们都使用相同的代码)，那么无论代码是否嵌入到应用程序(S)中，都没有多大的区别。

Answer 3

你在你的问题中已经总结了很多，我只想补充几点。

单一期权是使用第一种方法的NuGet包的一个很好的例子。

或者，如果您决定使用dll，您可以使用像科斯特拉这样的工具将该引用作为嵌入资源嵌入到可执行文件中。要使用它，只需添加Costura.Fody包：

Install-Package Costura.Fody