What is a circular dependency and how can I solve it?
Scenario
I have a solution on which I have (more than) 2 projects.
The first project has a project reference to the second project. The second project doesn't have a reference to the first project.
Well, in the first project I defined a inheritable class-type on which I would like that some classes from the second project inherits from it.
Problem
Obviouslly, If I want to inherit the type defined in the first project, in the second project I need to add a project reference to the first project to be able see the type and go on.
The problem is that when I try to add the project reference, I get this error message:
Question
Someone could explain me with other simple words (maybe with a code example too in case of code is implied in the error) what is a circular dependency?, and the most important thing: what can I do to solve it? (please read the last prhases of my research before answering).
Research
Is the first time that I hear the term "Circular dependency"; I've read this article from MSDN but I understood nothing.
Anyways I seen many questions of circular dependencys like this, and from what I've seen in that question seems that a circular dependency means that two projects cannot reference between them at the same time, just one of those two projects can reference the other; and also all the people who answered in that question said things like "Re-design is the solution" or "Circular dependencies are not good practices", however, re-designing in my case will mean define the same type in both projects, which I don't think that could be good practices neither, and of course building an additional assembly/project just to store a single type to reference that assembly in both projects ...is the worst idea I think.
Answer
A circular dependency is where Project A depends on something in Project B and project B depends on something in Project A. This means to compile Project A you must first compile Project B, but you can't do that as B requires A to be compiled. This is the problem that circular dependencies cause.
If you introduce a circular dependency to a project that you've already built it can be hard to spot as the standard build options don't remove the existing object files thus enabling you to build A (or B) first. You'll only spot it when you try on a different machine that's never built the solution before or if you do a clean & build.
re-designing in my case will mean define the same type in both projects, which I don't think that could be good practices neither.
In this case you need to create a third project "C" which contains the classes that both A and B depend on so they no longer depend on each other. You might get away with just splitting the classes up so that dependencies can be sorted that way without creating the third project.