tags:

views:

165

answers:

5

By other dependencies I mean abstract classes, and anything else.

I have a project in the form of a dll which needs a certain interface, IInput. A test project requires this interface as well, so I placed this interface in my main project, which in turn is a separate exe assembly.

This is because eventually the main project will need to use this interface when I wire everything together. Now the problem I had was when I attempted to add a reference in the main project to the dll with a reference to the main project I recieved a circular dependency.

I've never had this problem before, nor do I know the best way to counter it. As a temporary fix I've moved the interface to the separate dll, but very shortly I will require it in the main project so I'm back at square one.

Edit:

I should have mentioned the design, so here goes.

Menu
Menu Tests
Runner

Menu has IInput which is actually a interface adapater for a third party library in order to allow unit testing.

So a menu needs this for input, but so will the runner. The runner project (the exe) will require input so I will need IInput again.

+6  A: 

Since the interface shouldn't have any ties to either the test project or the main project, just move it to a seperate assembly, and reference this assembly from both test and main.

MySolution
 |->Interfaces.dll
 |->MainProject.exe (references Interfaces.dll)
 |->TestProject.exe (references Interfaces.dll)
Yannick M.
That's what I was thinking, but I've never heard of a sole assembly just for a couple of interfaces.
Finglas
I tend to use a "BusinessEntities" project and keep any interfaces there, be it for a couple or a large number. Works well.
Jeff Sargent
+2  A: 

Why not set up the structure like this:

Solution
  + Project With Interface
    - IInput
  + Main Project/UI
    -> Reference "Project With Interface"
  + Test Project
    -> Reference "Project With Interface"

No circular references, and it's really straight forward on the reference usage.

Agent_9191
+1  A: 

A circular dependency indicates an issue with your design. The interface should go wherever its definition belongs. If you have two interdependent projects, they probably either belong in one project, or (more likely)--if your dll is the "real" library, which your main project utilizes--then put the interface in the dll.

I say this with the assumption that by "dll" you mean "class library." If you literally mean a compiled dll to which you cannot make modifications, put the interface in a new library.

Dan Tao
A: 

I think the interface should be in the dll, and the main project should reference the dll, and have an adapter class which implements the interface. The test project will have a reference to the main project and the dll, i'd imagine.

Jimmeh
A: 

I don't think that this question is related exclusively to interfaces. It could just aswell have been an abstract class or something else. It sounds like there is something wrong with your overall architecture.

However, to fix the problem, just create a new class library containing the interface, that the other three projects can reference.

/Klaus

klausbyskov