Circular Dependency among two Projects of Different Solution

Question

Suppose there are two .net projects not under same solution. ProjectA is under solution1 and ProjectB is under solution2. ProjectA has a reference of ProjectB and ProjectB has reference of ProjectA. There are two classes ProjectA_Class and ProjectB_Class. ProjectA_Class creates the object of ProjectB_Class and ProjectB_Class creates the object of 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();
        }
    }
}

I am confused about circular dependency. Isn't it creates a circular dependency between two classes though they are not in the same solution? We know if this two projects reside in the same solution Visual studio won't allow us to reference ProjectA in ProjectB and ProjectB in ProjectA as it creates circular dependency. Isn't it create circular dependency among two projects still though they are not in the same solution? Suppose, there is a class C in ProjectA who creates an object of ProjectB_Class and ProjectB_Class does not use any instance of Class C. Isn't it a circular dependency as ProjectA and ProjectB both has reference of each other?

Update 1 Can you please explain the condition of circular dependencies?

Successor

Yes, it is a circular dependency. What is your question? – Tireless

Seems like your question should be "Why doesn't VS warn about these circular dependencies?" – Vesiculate

Actually I have an argument with a person regarding this and he told me that as they reside in different solution, it is not a circular dependency. Can you explain a bit more how it will be a circular dependency when there is a class C in ProjectA who creates an object of ProjectB_Class and ProjectB_Class does not use any instance of Class C. – Successor

Maybe there's confusion about different kinds of circular dependency. I thought at first you were talking about circular build dependency, now I see from the answers there's a more fundamental kind of circular dependency involved here. – Opulence

can you please explain a circular build dependency in the context of two projects? – Successor

Answer 1

If we're talking about circular build dependency, then that is the 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 is dependent on project A, because it references a class or something in project A. The problem with this is that the build system can't figure out which project to build first, and which to build second.

But you have a more weird kind of circular dependency in your posted code. The constructors of your two classes try to instantiate the other class, so A instantiates B which instantiates A which instantiates B which ... You get the idea.

EDIT:

Circular build dependency is, at least for all build systems I'm aware of, 100% dependent on how the projects reference each other. Visual Studio solutions are not involved at all, so it doesn't matter if the two projects are in the same solution or different solutions or are maybe even projects that are not part of a Visual Studio solution, for example machine-generated projects.

If you're not using an automated build system, but instead building the projects manually, then you are the build system. And how will you decide which project to build first and which to build second?

Opulence

Thanks for your answer. Actually I want an answer both from the view of circular build dependency and the more usual circular dependency. I have still a question remain for you. As I mentioned that ProjectA and ProjectB are in different solution, is it still a circular build dependency? Because the compiler won't build ProjectA and ProjectB at a time rather I need to build it by myself as they are not in the same solution. – Successor

Answer 2

Yes, it is a circular dependency.

Solutions and projects are just a way of organizing your files but the fact still remains that if 2 classes reference each other it is considered to be a circular dependency irrespective of them being in the same solution or not.

Seminarian

What will be the case when there is a class C in ProjectA who creates an object of ProjectB_Class and ProjectB_Class does not use any instance of Class C but ProjectA and ProjectB both has reference each other? – Successor

If your Class C calls a method in Class A that does something with Class B then that's fine but if you are using Class B from Class C in Class A then that violates LOD first of all. Second, if you're Class B still instantiates Class A in it then yes this case also creates circular dependency. – Seminarian

Answer 3

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

1. The classes are in different projects in different solutions.
2. The classes are in different projects in the same solution.
3. The classes are in the same project in the same solution.
4. The classes are in the same file in the same solution.

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

Now the real question is - why do you have a circular dependency (on purpose)?

Kepner

Actually I have an argument with a person regarding this and he told me that as they reside in different solution, it is not a circular dependency – Successor