"adding this project as a reference would cause a circular dependa

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am writing my first .NET C# application and I hit this message. I'm used to
working with object files and linking, and there was certainly never a
problem with classes in two different object files needing to reference each
other, or even two DLLs for that matter, so I don't understand why it's a
problem for .NET assemblies. Is there any way around this - not only is it
extremely annoying in that it forces me to arrange my software the way .NET
wants me to, rather than the way I want to, but it is also potentially
debilitating - it is not unheard of for a program's logic to require ClassA
to instantiate ClassB and for ClassB to instantiate ClassA - what does the
poor developer do then?
 
Dave said:
I am writing my first .NET C# application and I hit this message. I'm used
to
working with object files and linking, and there was certainly never a
problem with classes in two different object files needing to reference
each
other, or even two DLLs for that matter, so I don't understand why it's a
problem for .NET assemblies. Is there any way around this - not only is it
extremely annoying in that it forces me to arrange my software the way .NET
wants me to, rather than the way I want to, but it is also potentially
debilitating - it is not unheard of for a program's logic to require ClassA
to instantiate ClassB and for ClassB to instantiate ClassA - what does the
poor developer do then?
Click to expand...

Restructure his classes to remove this circular dependency. This is not a
good idea IMO, regardless of whether the development infrastructure lets
you do it or not. In the case of .NET, the only thing you are forced to do
is put ClassA and ClassB in the same assembly. If they are that closely
related that they are actually instantiating each other, I fail to see a
reason why someone should want them in two different assemblies.



Oliver Sturm
 
I'm not sure I understand your answer. Are you saying it is not a good idea
to restructure my classes ("his classes" means me, presumably)? If so, I
agree, but what else can I do? You say I shouldn't restructure my classes,
but then you say I must. Putting them in the same assembly IS restructuring.
Maybe my example was simplistic. I am writing a distributed client/server
system using remoting. The two applications (client and server) share some
classes, so these must be in an assembly of their own (as .NET seems to have
no other way of sharing code). The client must reference the server, and
certain methods in the shared classes call certain other methods in both the
client and the server. This would be perfectly legitimate in C++, and I don't
see why I can't do it in .NET.
Nevertheless I take it form your answer that, however unnecessary this
restriction is, there is no way round it. Is that correct?
 
Dave said:
I'm not sure I understand your answer. Are you saying it is not a good idea
to restructure my classes ("his classes" means me, presumably)?
Click to expand...

You asked: ... it is not unheard of for a program's logic to require
ClassA to instantiate ClassB and for ClassB to instantiate ClassA - what
does the poor developer do then?

And I said: Restructure his classes to remove this circular dependency.

So "he" is the poor developer you were using in your question, right?
Okay, he may be a she instead, sorry about that.

When I continued "This is not a good idea IMO...", I referred to the
scenario you had been describing, where classes A and B instantiate each
other. So to be clear, I mean you should restructure so that dependency is
linear, not circular.
Maybe my example was simplistic. I am writing a distributed client/server
system using remoting. The two applications (client and server) share some
classes, so these must be in an assembly of their own (as .NET seems to
have
no other way of sharing code). The client must reference the server, and
certain methods in the shared classes call certain other methods in both
the
client and the server. This would be perfectly legitimate in C++, and I
don't
see why I can't do it in .NET.
Click to expand...

I don't think this has anything to do with the language you're using. In a
common distributed application, there are usually three components: the
client, the server and the parts that both need to know about in order to
communicate. This makes three assemblies to me, at least (before taking
further modulerization on each the client and the server side into
account): "Common", which holds a few interfaces, maybe abstract classes,
maybe protocol constants, that kind of stuff, then "Client", local to the
client, which depends on "Common", and "Server", local to the server,
which depends on "Common" as well.

Consider this: if you were using any different kind of structure, you'd
have to deploy parts of your client application to the servers and parts
of the servers to the clients, right? So every time you fix a few bugs in
the client, for example, you're going to update all the servers as well?

These are the reasons why the type of direct dependencies between client
and server, as you described, are a bad idea in my opinion. Even if your
development/application environment doesn't force you to follow a linear
path of dependency, you should definitely do so. .NET forces you to do
this at least on the assembly level - this is unnecessary in the same way
that using strongly typed languages is unnecessary... you might be able to
get things right without them, but most people think they're still a good
idea.
Nevertheless I take it form your answer that, however unnecessary this
restriction is, there is no way round it. Is that correct?
Click to expand...

Yes, I believe there's no way around this.


Oliver Sturm
 
hi,

I'd just like to take issue about the circular dependencies. I also feel that this is a restriction which is unecessary. Okay it is good have nice linear code but sometimes you require these circular dependencies between classes which have an association but not a strong relation and therefore do not want to include them in the same assembly. What the .NET environment actually says is you can have circular dependencies but not over a number of assemblies. Why not? Going down this road means that you end up stuffing a bunch of classes which may have weak associations with each other into the same assembly and the logical grouping of the classes becomes messy and difficult to find. An example, I have a bunch of exceptions classes which I have in a ErrorManagement assembly and a bunch of logging classes in a LogManagement assembly. The in a single case an exception uses a log to log errors, and of course the logs use the exceptions to throw errors. Care is taken in the logs not to throw an exception which uses a log. The problem is that there is a circular dependency in the assemblies. The options available are to put the logs in the ErrorManagement (so I'm looking for a installation log class in ErrorManagement assembly? Not good!) or put the exceptions in the LogManagement (general error management classes in a LogManagement assembly? Not good) or stuff the lot into a rather ambiguous assembly called Common which can contain anything (Not good either.) If I want to find stuff to do with logs I want them in the LogManagement assembly, if I want error management stuff I want it in the ErrorManagement assembly. So I think the orignal writer of this article has a point, that we are being forced into doing things the .NET way instead of the way WE design our systems.

Thanks
Steve
 
Back
Top