What is a circular dependency and how can I solve it?

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.

What is a dependency?

In order to understand what circular dependency is, it is better to understand what is a dependency and what it means to the compiler.

Let's say you have a project and, in a class, you have the following defined:

Public Class MyClass
    'Some code here
    Private MyString As String
    'Some code there
End Class

When compiling your project, the compiler runs into the String class, which is defined in a DLL file called System. It will then link that DLL to your project, so at run-time, when defining or doing operation on the string, the System.dll will be loaded to perform those.

Now, let's say you have, further in your class, the following definition

'Some code here
Private MyObjet as CustomClass1
'Some code there

And let's say CustomClass1 is defined in another project of yours, named Project2.DLL:

Public Class CustomClass1
    'Your custom class code
End Class

So when compiling your first project, the compiler will run into CustomClass1 definition, it knows it lays into Project2.dll and therefore will compile Project2 before, in order to be able to add that reference in your first project.

That's what a dependency is, it's hierarchical, there must be a starting point. Even the String class is dependant on other classes, and at the end, they all rely on bytes or bits to do the job, because that's the only thing a computer can do, play with 1 and 0.

So the circular part

So if you have, in Project2, a reference (a field definition, or something like that) that link to your first project, what happens?

• The compiler reads your first project, then runs into CustomClass1
• Then it tries to compile Project2, since CustomClass1 is defined there
• Then it runs to a class defined in your first project
• It tries to compile your first project in order to link it to the second
• Then it runs to CustomClass1
• Then it tried to compile Project2
• I guess you got it...

So at some point the compiler displays an error, saying it cannot compile, as it doesn't understand what you're trying to do...

Yes, computers are that stupid.

How to solve it ?

Solving these kind of issue is sometimes difficult, but the basic idea is to build up a hierarchical structure, put the base class (those which don't need dependencies) together, then build up on them.

Take all the classes that depend on each other and put them together, they form a layer for something you try to do in your application.

Easiest way I know to fix CD is to create a PROJECT-of-Interfaces and have the projects that are involved in the CD to reference the PROJECT-of-interfaces, instead of each other. Little messy, but it works.