.NET 一个库中的多个类库答案

【问题标题】：.NET Multiple Class Library in One Library.NET 一个库中的多个类库
【发布时间】：2009-06-29 06:53:44
【问题描述】：

我在 VS2008 中工作。我有一个自定义类库 (CL1)，它引用了另一个自定义类库 (CL2)。这最终在我的发布文件夹中有 CL1 和 CL2。现在 CL1 的使用者需要在项目中包含两个我认为不合适的 dll。我有强烈的感觉，必须有一种方法来实现单个 DLL 解决方案。是否有推荐的（指南-d）方法来实现这一目标。

合并 CL1 和 CL2 不是一个选项，因为 CL2 更常见并且在多个其他项目/dll 中引用。我错过了一些直接的选择吗？或者我需要将 CL2 作为资源嵌入？如何？谷歌了网页，但在任何地方都找不到讨论的问题。

【问题讨论】：

为什么不直接分发这两个 DLL？这是在部署应用程序的过程中自动完成的。这样您就可以轻松地通过新版本更新它们。
我没有看到分发多个程序集的问题。这是很常见的事情 - 大多数 .Net 库都分为几个程序集，即使您没有明确使用它，也经常包含一个“核心”程序集。

标签： c# dll reference

【解决方案1】：

是的，您可以在使用 ILmerge 发布产品之前手动执行此操作。更多详情请访问 codeproject 和 Brad McCabe's 博客。

【讨论】：

我也是。我将对此进行更多研究。
这里是 Brad 的 MS 研究页面的链接，它可能也很有用 - research.microsoft.com/en-us/people/mbarnett/ilmerge.aspx
除了 ILmerge 之外，您还可以使用 ilasm 来强命名预构建程序集。欲了解更多信息，请阅读：andrewconnell.com/blog/archive/2004/12/15/772.aspx

【解决方案2】：

您可以将 CL2 的源代码作为链接文件包含在 CL1 项目中，并以此作为避免要求用户包含多个引用的一种方式。在我看来，这是一个坏主意。

如果您的类设计确实需要将您的类拆分为多个程序集，并且 CL1 需要引用 CL2，那么用户引用多个程序集是完全可以的——尤其是因为，正如您所说，程序集服务于不同的目的。

如果用户只使用 CL1 中的类，则他们不需要添加多个程序集作为引用。但是，如果 CL1 引用 CL2，则 CL2 将始终与 CL1 一起复制，即使对 CL2 的引用不是显式的。

【讨论】：

感谢您的回答。我在这里担心的是，CL2 就像我们部门的外部 dll，我们只能引用它。现在，CL2 仅在内部引用 CL1，而 CL1 的使用者与 CL1 无关 - 显然。我无法理解你的最后一句话“...CL2 将永远被复制...” - 你的意思是自动吗？我无法得到它。
更正 - 我很感激你的回答。我在这里担心的是，CL2 就像我们部门的外部 dll，我们只能引用它。现在，CL2 仅在内部引用 CL1，而 CL1 的使用者与 CL2 无关 - 显然。我无法理解你的最后一句话“...CL2 将永远被复制...” - 你的意思是自动吗？我无法得到它。
我的意思是，如果您正在创建引用 CL2 的 CL1，那么 CL2 最终会出现在您的构建输出中。您的用户将引用 CL1，它将 CL1 复制到他们的构建目录中。 CL2 也会自动被复制，因为 CL1 需要它，即使用户没有专门添加对 CL2 的引用。用户必须添加 CL2 作为引用的唯一情况是，如果您的 CL1 中的类继承自 CL2 中的类，或者使用类作为方法参数等...是这种情况吗？
hmmm...当这一切都在同一个开发网络中完成时，看起来还不错。如果我在外部计算机上发送 dll - 我将不得不发送两个 dll。
通常的做法是包括所有构建输出的东西（在这种情况下是两个程序集）。您的程序集具有依赖关系这一事实并不是一件可怕的事情。如果您的程序集在添加功能时承担了其他依赖项（或者这不是问题），会发生什么？

【解决方案3】：

好吧，您可以将 CL2 嵌入到 CL1 中，并在需要时使用 AssemblyResolve 事件来提取它，我真的不建议您这样做。只需在发行版中包含 DLL，我会说这是分发它的正常方式。

【讨论】：

感谢弗雷德里克的回复。当 dll 的使用者只打算使用主 dll 类时，分发多个 dll 是否正常。没有办法将多个dll打包在一起。我知道将 dll 作为二进制文件嵌入不是一个好主意。

【解决方案4】：

我相信这个问题可能会给你想要的答案：

How to link a .DLL statically?

【讨论】：

我们的都是 C# 库。我找不到在答案中静态链接 dll 的方法，并且不确定它是否能解决问题。无论如何，谢谢。