不同解决方案的两个项目之间的循环依赖

Question

假设有两个 .net 项目不在同一个解决方案下。 ProjectA 在solution1 下，ProjectB 在solution2 下。 ProjectA 有 ProjectB 的引用，ProjectB 有 ProjectA 的引用。有两个类 ProjectA_Class 和 ProjectB_Class。 ProjectA_Class 创建 ProjectB_Class 的对象，ProjectB_Class 创建 ProjectA_Class 的对象。

namespace ProjectB
{
    public class ProjectB_Class
    {
        public ProjectB_Class()
        {
            ProjectA_Class projA = new ProjectA_Class();
        }
    }
}

namespace ProjectA
{
    public class ProjectA_Class
    {
        public ProjectA_Class()
        {
            ProjectB_Class projB = new ProjectB_Class();
        }
    }
}

我对循环依赖感到困惑。尽管它们不在同一个解决方案中，但它不是在两个类之间创建循环依赖吗？我们知道这两个项目是否驻留在同一个解决方案中，Visual Studio 不允许我们在 ProjectB 中引用 ProjectA，在 ProjectA 中引用 ProjectB，因为它会创建循环依赖。尽管它们不在同一个解决方案中，但它是否仍然在两个项目之间创建循环依赖？假设ProjectA中有一个类C，它创建了一个ProjectB_Class的对象，而ProjectB_Class没有使用任何C类的实例。难道ProjectA和ProjectB都有相互引用的循环依赖吗？

更新 1 你能解释一下循环依赖的情况吗？

Answer 1

是的，是循环依赖。

解决方案和项目只是组织文件的一种方式，但事实仍然是，如果 2 个类相互引用，则无论它们是否在同一个解决方案中，都被视为循环依赖。

Answer 2

如果我们谈论的是循环 build 依赖，那么当项目 A 依赖于项目 B 中的某些东西时，这就是问题所在，例如通过引用项目 B 中的一个类。同时项目 B 依赖于项目 A，因为它引用了项目 A 中的一个类或某些东西。这样做的问题是构建系统无法确定首先构建哪个项目，然后再构建哪个项目。

但是您发布的代码中有一种更奇怪的循环依赖。你的两个类的构造函数试图实例化另一个类，所以 A 实例化 B 实例化 A 实例化 B ......你明白了。

编辑：

循环build 依赖，至少对于我所知道的所有构建系统来说，100% 依赖于 projects 如何相互引用。根本不涉及 Visual Studio 解决方案，因此无论这两个项目是在同一个解决方案还是不同的解决方案中，或者甚至可能是不属于 Visual Studio 解决方案的项目，例如机器生成的项目，都没有关系。

如果您不使用自动构建系统，而是手动构建项目，那么您就是构建系统。您将如何决定先构建哪个项目，然后再构建哪个项目？

Answer 3

循环依赖在类之间。这与项目和/或解决方案的组织无关。以下所有情况的问题都是相同的：

1. 这些类位于不同解决方案的不同项目中。
2. 类位于同一解决方案的不同项目中。
3. 这些类在同一个解决方案的同一个项目中。
4. 这些类在同一个解决方案中的同一个文件中。

循环依赖是一个编译错误，由于编译器对类型的处理方式无论它们位于何处，循环依赖仍然存在。

现在真正的问题是 - 为什么你有一个循环依赖（故意）？