通俗地描述.NET程序集循环依赖问题
请通俗地描述一下.NET程序集编译循环依赖问题，以及其他技术是否有类似的限制。
注意：我知道，这似乎是一个简单的问题，但我见过许多真实的、重要的项目，它们完全破坏了依赖关系图。
Please describe the .NET assembly compilation circular dependency problem in layman's terms, and whether other technologes have similar limitations.
Note: This seems like a simple question, I know, but I have seen a number of real, significant projects that have totally broken dependency graphs.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
与任何其他循环依赖相同...
考虑三个程序集 A、B 和 B。 C
A 需要 B 中定义的内容，B 需要 C 中定义的内容，C 需要 A 中定义的内容。
您可以先构建哪个？
Same as any other circular dependency...
Consider three assemblies A, B & C
A needs something defined in B, B needs something defined in C, and C needs something defined in A.
Which can you build first?
补充一下 Lucas 的答案：在 .NET 中很难提出循环程序集依赖关系。为了编译
A.dll，您首先需要B.dll；要编译B.dll，您首先需要C.dll；但要编译C.dll，您需要首先尝试编译的A.dll。可能遇到这种情况的唯一方法是，如果您并行开发 A、B 和 C，并且意外地引入了循环依赖项。但是，一旦您对所有三个进行了干净的构建，问题就会显而易见，并且在打破循环之前您将无法继续。
单个依赖项中的命名空间和/或类之间的循环依赖项更为常见。我尝试将这种循环依赖视为一种代码味道；组件之间没有循环依赖关系的代码库是那些组件可以轻松保持分离和独立重构的代码库。
Patrick Smacchia（NDepend 人员）在这里谈论了一些依赖循环及其对代码质量的影响：http://codebetter.com/blogs/patricksmacchia/archive/2009/07/29/maintainability-learnability-component-layering.aspx
To add to Lucas's answer: it's very hard to come up with a circular assembly dependency in .NET. In order to compile
A.dllyou first needB.dll; to compileB.dllyou first needC.dll; but to compileC.dllyou need theA.dllyou were trying to compile in the first place.The only way you're likely to get into this situation is if you're developing A, B and C in parallel, and you've managed to introduce a circular dependency by accident. But as soon as you do a clean build of all three, the problem will be apparent, and you won't be able to proceed until you break the cycle.
Circular dependencies between namespaces and/or classes within a single dependency are a lot more common. I try to treat this kind of circular dependency as a code smell; a codebase without circular dependencies between components is one where those components can easily be kept separate and refactored independently.
Patrick Smacchia (the NDepend guy) talks a little about dependency cycles and their effect on code quality here: http://codebetter.com/blogs/patricksmacchia/archive/2009/07/29/maintainability-learnability-component-layering.aspx
我是 .NET 开发人员工具 NDepend 的开发人员之一，该工具专门用于强制执行干净的代码结构并消除依赖循环。在我们的产品网站上，您会找到与组件依赖周期问题相关的两本白皮书：
通过 .NET 程序集和 Visual Studio 项目对代码库进行分区（8 页）
使用命名空间定义 .NET 组件（7 页）
I am one of the developer of the tool NDepend for .NET developers that is specialized in enforcing clean code structure and remove dependency cycles. On our product site you'll find two white-books relative to the component dependency cycle issue:
Partitioning code base through .NET assemblies and Visual Studio projects (8 pages)
Defining .NET Components with Namespaces (7 pages)