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?
A circular dependency occurs when two classes depend on each other. For example, class A needs class B, and class B also needs class A. Circular dependencies can arise in Nest between modules and between providers. While circular dependencies should be avoided where possible, you can't always do so.
In software engineering, a circular dependency is a relation between two or more modules which either directly or indirectly depend on each other to function properly. Such modules are also known as mutually recursive.
Ideally, circular dependencies should be avoided, but in cases where that's not possible, Nest provides a way to work around them. A forward reference allows Nest to reference classes that have not yet been defined by using the forwardRef() utility function.
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.
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?
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:
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)?
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With