通俗地描述.NET程序集循环依赖问题答案

【问题标题】：Describe the .NET assembly circular dependency problem in layman's terms通俗地描述.NET程序集循环依赖问题
【发布时间】：2011-03-19 06:30:26
【问题描述】：

请通俗地描述一下.NET程序集编译循环依赖问题，其他技术是否有类似限制。

注意：这似乎是一个简单的问题，我知道，但我已经看到了许多真正的、重要的项目完全破坏了依赖关系图。

【问题讨论】：

【解决方案1】：

我是工具NDepend 的开发人员之一，该工具专门用于强制执行干净的代码结构和消除依赖循环的 .NET 开发人员。在我们的产品网站上，您会找到与组件依赖周期问题相关的two white-books：

【讨论】：

【解决方案2】：

补充卢卡斯的答案：在.NET 中很难提出循环程序集 依赖项。为了编译A.dll，你首先需要B.dll；编译B.dll首先需要C.dll；但是要编译C.dll，您需要首先尝试编译的A.dll。

您可能会遇到这种情况的唯一方法是，如果您正在并行开发 A、B 和 C，并且您无意中引入了循环依赖项。但是，一旦您对所有三个都进行了干净的构建，问题就会很明显，并且在您打破循环之前您将无法继续。

单个依赖项中命名空间和/或类之间的循环依赖项更为常见。我尝试将这种循环依赖视为代码异味；组件之间没有循环依赖的代码库是那些组件可以很容易地保持分离和独立重构的代码库。

【讨论】：

【解决方案3】：

与任何其他循环依赖相同...

考虑三个程序集 A、B 和 C

A 需要 B 中定义的东西，B 需要 C 中定义的东西，C 需要 A 中定义的东西。

你可以先构建哪个？

【讨论】：

你甚至不需要三个 - 只是 A 需要 B 中的某些东西，B 需要 A 中的某些东西。
确实如此。我用了三个，因为两个不“感觉”循环，更像是“乒乓依赖”:)
是否可以在编译过程结束时编译成中间元程序集，以便根据项目进行拆分？
@Ben Aston - 可能是这样，但更好（IMO）会移动一些东西，这样你就不再有循环依赖了。如果您添加一些详细信息，也许我们可以帮助您（或在新问题中提出）。
@Lucas，谢谢。我在假设性地思考。我有兴趣探索 VS 中程序集之间的循环依赖限制在多大程度上是人为与真实的。