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 wrote:

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?
Show quoteHide quote

Dave wrote:

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.

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.

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


                Oliver Sturm

Whats an efficient way of insertring elements into an XML document
byte[] <=> sbyte[]
Writing Stream to File
How can i connect and login to Windows 2000 server from c# code?
How do I clean the cache?