Cyclic DLL references

  • Thread starter Thread starter Yair
  • Start date Start date
Y

Yair

Is it possible in any way to have a cyclic DLL reference
in .NET? (We need DLL A to hold a reference to DLL B, and
vice versa). If it is not possible, does anyone know of
any good trick of how to accomplish this?
Thank you in advance.
 
What do you want to use the cyclic dependency for? Maybe you can introduce a
third dll defining common interfaces and reference to that in both dlls. The
classed you want to be able to communicate with each other can then be
derived from one of these interfaces.

You now have three Dlls: A, B and Interfaces
A references B and Interfaces
B references only Interfaces

Let's say you want to use some class from A in B, set a static
member(datatype: interface defined in interfaces) of some class in B to a
valid object from A by a call from A. Any class in B can now access this
member and the object implementing the interface.

DLL: Interfaces
interface IAClass
{
foo();
}

DLL:A
class AClass:IAClass
{
foo(){...}
setClass()
{
BClass.aclass=this;
}

}

DLL:B
class BClass
{
public static IAClass aclass;
bar()
{
aclass.foo();
}
}


Or create the object via reflection (class Activator + GetType(...) from the
Assembly-Object of A found in AppDomain.CurrentDomain.GetAssemblies()).

Anyone got a better idea?

mat
 
Hi,
Thank you for your reply.
The reason me need to have cyclic references is that we
are working on quite a large project, and
we have now reached the conclusion that we need to
seperate a certain DLL to about a dozen DLL's (so that it
will be easier for the developers to work on their models).
The problem is that we have cyclic dependencies in this
DLL.
The only problem with your proposal is the perforance
penalty (quick access from A to B, and from B to A is a
key issue).
Anyway, thanks alot. We'll keep thinking about it :-)...
 
Yair said:
Hi,
Thank you for your reply.
The reason me need to have cyclic references is that we
are working on quite a large project, and
we have now reached the conclusion that we need to
seperate a certain DLL to about a dozen DLL's (so that it
will be easier for the developers to work on their models).
The problem is that we have cyclic dependencies in this
DLL.
The only problem with your proposal is the perforance
penalty (quick access from A to B, and from B to A is a
key issue).
Click to expand...

Are you *sure* it's a problem? Have you tested it and measured the
performance penalty? You may well find it's not nearly as bad as you
think, and not enough to be a problem.
 
Try this:
Step 1. A, standalone.
2. Add B, reference A.
3. Rebuild A, reference B.
Now you have cyclic dependency between A and B.
 
Back
Top