Circular dependencies

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Joe M. - 25 Oct 2005 22:37 GMT

Hello.

Can someone explain to me or point me to documentation about why circular
dependencies are not allowed between projects in Visual C# .NET? I'm
assuming it's because of the CLR and how the compiler generates assemblies
but I'm having trouble finding specifics on MSDN and the web.

I'm embarrassed at how basic this question could be but I'm coming from Java
(and no C++) and I'd like to understand it.

Thank you for your consideration.

Joe

Reply to this Message

Ivan Wong - 26 Oct 2005 04:53 GMT

This is how Garbage Collector in .NET works, when two object refer to each
other, and those two objects are not being referenced by any object. GC will
assume that those two objects are garbage. You could search "How Garbage
Collector works" in msdn library, there is heaps of article you could read tho

Hope it helps,
Ivan wong

> Hello.
>
[quoted text clipped - 9 lines]
>
> Joe

Reply to this Message

Oliver Sturm - 26 Oct 2005 17:38 GMT

>Can someone explain to me or point me to documentation about why circular
>dependencies are not allowed between projects in Visual C# .NET? I'm
[quoted text clipped - 4 lines]
>Java
>(and no C++) and I'd like to understand it.

Nothing particularly basic about that question, I guess - as a matter of
fact, I have trouble coming up with an exacty reasoning for the decision
to disallow circular dependencies.

The obvious thing is that potential circular dependencies between a set of
assemblies would complicate the algorithms enormously that need to find a
proper load order at a given point. I'm not saying it would be impossible,
but it would be more complicated and error prone. It might over all
decrease application performance because larger numbers of assemblies
would have to be loaded at once because of their dependencies, although
their code might not be needed. OTOH, the current restriction results in a
nice and clean dependency hierarchy.

Now the other way round: why would you want to use circular dependencies?
With classes, it is widely regarded as bad practice to have circular
dependencies. The assembly is a larger management unit, but for me the
same reasons of common sense apply - you should be able to separate your
classes into groups that have linear dependencies amongst each other. If
that seems impossible to do, you should really reconsider your application
design.

Signature

Oliver Sturm
Developer Express Inc.

Reply to this Message

Matthijs van der Vleuten - 26 Oct 2005 19:42 GMT

> The obvious thing is that potential circular dependencies between a set
> of assemblies would complicate the algorithms enormously that need to
[quoted text clipped - 4 lines]
> dependencies, although their code might not be needed. OTOH, the current
> restriction results in a nice and clean dependency hierarchy.

According to Reflector (1), System.dll depends on System.Xml.dll, which
in turn depends on System.dll again. (At least on 1.1.)
Classes in the System.Configuration namespace appear to use classes in
the System.Xml namespace.
Classes in the System.Xml assembly appear to use classes in the
System.CodeDom, System.Collections.Specialized, System.ComponentModel,
System.Diagnostics, System.Net, System.Text and System.Uri namespaces.

(1) http://www.aisto.com/roeder/dotnet/

Reply to this Message

Oliver Sturm - 27 Oct 2005 09:29 GMT

>According to Reflector (1), System.dll depends on System.Xml.dll, which
>in turn depends on System.dll again. (At least on 1.1.)
[quoted text clipped - 3 lines]
>System.CodeDom, System.Collections.Specialized, System.ComponentModel,
>System.Diagnostics, System.Net, System.Text and System.Uri namespaces.

One important thing: be careful with the terms here. Although namespaces
tend to live completely in single assemblies (I mean, that's how I and
most other people I know usually do it in our own projects), they don't
have to - and in the case of the .NET framework assemblies there are
actually a lot of cases where namespaces overlap assembly borders. So to
say that classes in a given namespace depend on ones in another doesn't
say anything about the assembly structure.

Anyway, you're right about the dependencies in System.dll. I have no idea
why - or even exactly how - Microsoft did that. I don't think there's any
legitimate way to achieve this result and I stand by my opinion that
there's nothing desirable about it.

Signature

Oliver Sturm
Developer Express Inc.

Reply to this Message

Robert Jordan - 27 Oct 2005 09:35 GMT

>> According to Reflector (1), System.dll depends on System.Xml.dll, which
>> in turn depends on System.dll again. (At least on 1.1.)
[quoted text clipped - 16 lines]
> there's any legitimate way to achieve this result and I stand by my
> opinion that there's nothing desirable about it.

It's done with conditional compiling. The corlib gets first compiled
w/out the XML stuff. After that, System.Xml is compiled as usual.
When System.Xml is ready, the corlib is recompiled, now with
conditionally enabled System.Xml references.

Rob

Reply to this Message

EP - 21 Nov 2005 22:16 GMT

If you have 3 projects, A depends on B, B depends on C, C depends on A....

Who should visual studio compile first?

Visual studio bases it's build order on references. It will first compile
a project that doesn't depend on any other projects in the solution. If
Each project depends on at least someone else, it doesn't know who to compile
first.

I suspect you came into a circular dependency after you'd already compiled
earlier versions of the dlls..... just try to imagine if you had only source
code, how you would compile the dlls.

Hello Joe M.,

> Hello.
>
[quoted text clipped - 10 lines]
>
> Joe

Reply to this Message

Rate this thread:

Circular dependencies

Free Magazines