关于.net中DLL的循环依赖关系的“最佳”实践是什么？
我正在尝试使用DLL来进行需要读/写XML的错误处理/日志记录。
我已经有几个类来帮助在单独的“实用程序”类型DLL中进行XML操作。
将我的fancy-pants错误处理类合并到实用程序DLL中会很好，但我还需要用于错误记录DLL的XML操作代码。
我在想我应该保持DLL的分离，以便在其他项目中重复使用，但现在我不确定最好的方法是什么。
有关如何处理此方案的任何建议？
答案 0 :(得分：10)
处理它的一种方法是将一个部件合并到另一个部件的组件中。我的经验是，人们倾向于将他们的项目分成许多小型程序集，这些程序集并没有真正改进任何东西，但会导致依赖性问题。
我一般都提倡很少的大集会。使用程序集作为部署单元，而不是构造代码。使用命名空间构建代码。
解决此问题的另一种方法是在公共程序集中或在两个现有程序集之一中引入接口。如果接口方法本身没有循环依赖，但方法体具有。
，则后一种情况是有意义的答案 1 :(得分：8)
这里有两本白皮书，深入探讨.NET程序集和命名空间中代码分区的主题，涵盖循环依赖项的原因和方式。它与 usr 建议的方向相同：极少数大型程序集，使用程序集作为部署单元，而不是构造代码。使用命名空间构建代码。
Partitioning code base through .NET assemblies and Visual Studio projects（8页）
Defining .NET Components with Namespaces（7页）