Circular relationship between two projects of different solutions

Question

Assume that there are two .net projects not under the same solution. ProjectA is in solution 1, and ProjectB is in solution2. ProjectA has a link to ProjectB, and ProjectB has a link to ProjectA. There are two classes ProjectA_Class and ProjectB_Class. ProjectA_Class creates a ProjectB_Class object, and ProjectB_Class creates a ProjectA_Class object.

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(); } } } 

I got confused in a circular dependence. Does this not create a circular relationship between the two classes, although they are not in the same solution? We know whether these two projects are in the same solution. Visual Studio will not allow us to reference ProjectA in ProjectB and ProjectB in ProjectA, since it creates a circular dependency. Does this not create a circular relationship between the two projects, although they are not in the same solution? Suppose there is a class C in ProjectA that creates a ProjectB_Class object, and ProjectB_Class does not use any instance of class C. Is it not a circular dependency, since ProjectA and ProjectB have a reference to each other?

Update 1 Could you explain the condition of circular dependencies?

Answer 1

If we talk about the cyclical dependency of the assembly, then this is a problem when project A depends on something in project B, for example, by referencing a class in project B. And at the same time, project B depends on project A, because it refers to a class or something in project A. The problem is that the build system cannot determine which project to build first and which second.

But you have a weirder view of circular dependency in your hosted code. The constructors of your two classes are trying to create an instance of another class, so A creates an instance of B, which creates an instance of A, which creates B, which ... You get the idea.

EDIT:

The cyclic build dependency is, at least for all build systems that I know of, 100% dependent on how the projects reference each other. Visual Studio solutions are not involved at all, so it doesn’t matter if these two projects are in the same solution or in different solutions, or maybe even in projects that are not part of the Visual Studio solution, for example, projects created by the machine.

If you are not using an automatic build system, but instead create projects manually, then you are a build system. And how do you decide which project will be built first and which will be built second?

Answer 2

Yes, it is a circular addiction.

Solutions and projects are just a way of organizing your files, but the fact remains: if 2 classes refer to each other, they are considered a cyclic dependency, regardless of whether they are in the same solution or not.

Answer 3

Circular dependency between classes. This has nothing to do with the organization of the project and / or decisions. The problem will be the same for all of the following situations:

• Classes are in different projects in different solutions.
• Classes are in different projects in the same solution.
• Classes are in the same project in the same solution.
• Classes are in the same file in the same solution.

A circular dependency is a compilation error, and since the compiler treats types the same way wherever they are, a circular dependency still exists.

Now the real question is: why do you have circular addiction (as intended)?