CODEWITHSUNDEEP
c#visual-studiodependenciespackage-design
mrblah
mrblah

Reputation: 103577

Circular dependencies

I have 2 projects.

Project#2 has a reference to Project#1

Now I need to reference Project#2 in Project#1, but vs.net is complaining about a circular dependency.

Is there a way out of this?

Upvotes: 46

Views: 72340

Answers (13)

angelo.mastro
angelo.mastro

Reputation: 1784

In C++ you can forward declare class B, if class A depends on it. Something like that.

// segment.hpp
class Polygon;  // fwd declare

class Segment {
  public:
    bool Intersects(Polygon p);
};

and

// polygon.hpp
class Segment; // fwd declare

class Polygon {
  public:
    bool Intersects(Segment s);
};

While in C# you could create an extension module, far away from both. Something like that

// Segment.cs
namespace MyLib {

public class Segment {
  // ...
}

}

and

// Polygon .cs
namespace MyLib {

public class Polygon {
  // ...
}

}

and a third file

// Extensions.cs
namespace MyLib {

public static class Extensions {

   public static bool Intersects(this Segment s, Polygon p) { //... }
   public static bool Intersects(this Polygon p, Segments) => s.Intersects(p);

}

}

and then you will haver no circular dependencies and get this result.

// Program.cs

using MyLib; // that's all you need

namespace ConsoleApp {
  internal class Program {
    static void Main(string[] args) {

       var s = new Segment(...);
       var p = new Polygon(...);
       bool intersects = p.Intersects(s);

    }
  }
}

Upvotes: 0

Oskar Zdrojewski
Oskar Zdrojewski

Reputation: 79

Contrary to what's been said before, circular dependencies are sometimes unavoidable. For sure there are benefits to linear designs (maintainability, readability, debugging etc.) but it makes no sense to give up circularity/bidirectionality if it is going to make you give up on splitting projects based on their functionality (which wouldn't help you maintain or understand the code).

Solution: You have to use a project with interfaces to which both of said projects reference to. Classes from higher level projects contain implement interfaces from the interface project. This way you can expose method implementations and classes in a circular manner.

Some pseudocode:

Project Interface

interface IApple { void dropOnHead(IPerson person);}
interface IPerson { void eatApple(IApple apple);}

Project#1

using ProjectInterfaces;
class Apple : IApple{
  void dropOnHead(IPerson person) { log("bop");}
}

Project#2

using ProjectInterfaces;
class Person : IPerson{
  void dropOnHead(IApple apple) { log("crunch");}
}

Upvotes: 1

user2555515
user2555515

Reputation: 1043

Everyone will tell you this is a bad design do not do it etc. However sometimes it is easier said than done and moving the implementation into a separate common code is not desirable. For such cases instead of calling the other package directly, emit an event from one package and handle it in the other. That way you do no need to make the other component a dependency in the first component.

Another way if you still want to keep the implementation in separate packages is to derive your logic classes form interfaces and define those in a separate package. This works if you have a way to instantiate the implementation, for example via dependency injection or other means.

Upvotes: 3

Craig Wilson
Craig Wilson

Reputation: 12624

Absolutely not. Circular dependencies are a indication of bad design. I don't mean to be harsh. There are some ways out of this.

1) You can refactor common code to another project, say Project#0

2) You can fix your design, which is probably the way to go.

Uncle Bob has a good article on Packaging Principles which includes the Acyclic Dependencies Principle. http://www.objectmentor.com/resources/articles/granularity.pdf. Read this to know why cyclic dependencies are a bad thing.

Upvotes: 86

K.B.Raj
K.B.Raj

Reputation: 15

I don't think it is a good solution but still we can do by following these steps

  • add the reference
  • browse and
  • go to Debug folder of dll project,
  • find the .dll and Add .

Upvotes: -5

Amit
Amit

Reputation: 3478

This seems to be a design flaw, nothing else. Re-design is the solution.

Upvotes: 1

Alfred Myers
Alfred Myers

Reputation: 6453

Circular reference can be done as seen in a previous question, but you should not do it for the reasons everybody already stated here.

Upvotes: 4

R Samuel Klatchko
R Samuel Klatchko

Reputation: 76571

A circular dependency means that these are no longer two independent projects (because there it is impossible to build only one of them).

You need to either refactor so that you have only a one way dependency or you should merge them into a single project.

Upvotes: 5

David
David

Reputation: 73574

I really don't mean to be a smart-aleck, but better program design is the answer.

Upvotes: 1

codekaizen
codekaizen

Reputation: 27429

Refactor your projects to take the common elements out into a "Project #0" which both Project #1 and Project #2 reference.

Upvotes: 17

Adam Ralph
Adam Ralph

Reputation: 29956

This points to a problem in your design. If there is a genuine need for two or more of your types to be mutually aware then they should exist in the same assembly.

Upvotes: 5

wj32
wj32

Reputation: 8403

No. Structure your projects properly. Try using some sort of ordering based on abstraction - low-level to high-level.

Upvotes: 3

David M
David M

Reputation: 72890

Merge the two into one or redesign.

Upvotes: 8

Related Questions