我正在创建一个类库（MyLib），它包含一个公共类A.该类指定一个公共方法M从外部类库（ExtLib）返回一个B类实例。
为了使用MyLib.A.M（），将使用我的类库的用户必须引用MyLib和ExtLib。
我的问题是，可以通过MyLib直接访问ExtLib.B类（例如：MyLib.B），因此用户不必引用这两个库，但只能引用MyLib？
答案 0 :(得分：1)
您应该接受您的用户应该引用您的程序集和支持程序集。
是的，你可能会让ilmerge工作，所以支持组件整体合并到你自己的组件中。但这完全将你的组装发布时间表与支持组件联系在一起。支持组件无法更新以便与您的组件一起使用，而无需重新发布您自己的组件。
还有版权和许可问题。如果你也写了支持组件，我想你应该没有任何问题。但是否则，将支持组件与你自己的组合在一起可能至少会受到该组装作者的不满，如果不是完全禁止的话。
另一个令人讨厌的选择可能是从程序集的API返回dynamic个对象，而不是支持程序集中声明的类型。这当然会产生性能影响，并且会否定任何可能的编译时类型安全性，否则这将是使用像C＃这样的语言的正常好处。但它可以做到。
如果您真的不能忍受用户添加对支持库的引用的想法，从软件工程的角度来看，合理的选择是更改程序集的API，以便它不会从支持库返回类型。如果你使用它们，它们仍然需要在运行时组装，但至少用户的代码不需要显式引用。相反，您的API将返回您自己的程序集声明的类型以及包含支持程序集类型的类型，可能会修改这些类型的接口（删除不需要的成员，添加新扩展等）以更好地满足您自己的用户需求。这样，支持程序集的类型在视图中是隐藏的，因此不需要用户程序集的明确引用。
恕我直言，值得注意的是，你的用户已经引用了你的程序集所依赖的许多其他程序集，即如果没有其他程序，那么至少是各种.NET程序集。当然，其中许多是完全可以使用的.NET代码所必需的，因此用户的项目已经具有这些引用，但它们仍然代表其他程序集引用。其他非默认的.NET程序集可能需要也可能不需要，具体取决于您自己的程序集使用的其他内容并返回到用户的代码。无论如何，这种事情是非常普遍的，并不是真正需要花费大量时间来避免的事情。
同样，事实是无论如何都需要在运行时支持组件。因此，要求程序集由用户自己的项目引用似乎并不困难。引用声明类型一个人自己的代码所依赖的程序集就是.NET的工作原理。为什么打架呢？有什么令人信服的问题可能会激发任何真正的努力来避免用户项目的额外参考？