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

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

这些课程在不同的解决方案中处于不同的项目中。
这些类在同一解决方案中的不同项目中。
这些类在同一个解决方案中属于同一个项目。
这些类在同一解决方案中位于相同的文件中。

循环依赖是一个编译错误，并且由于编译器以相同的方式处理类型，因此循环依赖性仍然存在。

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

Answer 3

如果我们谈论循环构建依赖关系，那么当项目A依赖于项目B中的某些内容时，这就是问题，例如通过引用项目B中的类。同时，项目B依赖于项目A，因为它引用了项目A中的类或类。问题是构建系统无法确定首先构建哪个项目，以及构建第二个项目。 / p>

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

编辑：

循环构建依赖性，至少对于我所知道的所有构建系统而言，100％依赖于项目如何相互引用。 Visual Studio解决方案根本不涉及，因此如果两个项目位于相同的解决方案或不同的解决方案中，或者甚至可能是不属于Visual Studio解决方案的项目，例如机器生成的项目，则无关紧要。

如果您没有使用自动构建系统，而是手动构建项目，则您是构建系统。您将如何决定首先构建哪个项目以及构建第二个项目？

两种不同解决方案的循环依赖性

3 个答案: