+1  A: 

I guess it could be done by starting with an acyclic set of assemblies and using ILMerge to then coalesce the smaller assemblies into logically related groups.

Steve Gilham
A: 

One possible approach is to use conditional compilation (#if) to first compile a System.dll that doesn't depend on those other assemblies, then compile the other assemblies, and at last recompile System.dll to include the parts depending on Xml and Configuration.

Daniel
Unfortunately this doesn't allow you to conditionally reference an assembly (I wish it was possible, it would really help in one of my projects...)
Thomas Levesque
Conditional references can be easily done by editing the .csproj file. Just add a Condition attribute to the <Reference> element.
Daniel
+32  A: 

I can only tell how the Mono Project does this. The theorem is quite simple, though it gives a code mess.

They first compile System.Configuration.dll, without the part needing the reference to System.Xml.dll. After this, they compile System.Xml.dll the normal way. Now comes the magic. They recompile System.configuration.dll, with the part needing the reference to System.Xml.dll. Now there's a successful compilation with the circular reference.

In short:

  • A is compiled without the code needing B and the reference to B.
  • B is compiled.
  • A is recompiled.
Dykam
It's blocked by Visual Studio, but can be done using the command line compiler (csc.exe) directly. See my answer.
Alfred Myers
I know. Mono's main build system isn't Visual Studio. Guess Microsofts isn't either.
Dykam
+1  A: 

Well, I've never done it on Windows, but I have done it on a lot of the compile-link-rtl environments that served as the practical progenitors for it. What you do is first make stub "targets" without the cross-references then link, then add the circular references, then re-link. The linkers generally do not care about circular refs or following ref chains, they only care about being able to resolve each reference on it's own.

So if you have two libraries, A and B that need to reference each other, try something like this:

  1. Link A without any refs to B.
  2. Link B with refs to A.
  3. Link A, adding in the refs to B.


Dykam makes a good point, It's compile, not link in .Net, but the principle remains the same: Make your cross-referenced sources, with their exported entry points, but with all but one of them having their own references to the others stubbed out. Build them like that. Then, unstub the external references and rebuild them. This should work even without any special tools, in fact, this approach has worked on every operating system that I have ever tried it on (about 6 of them). Though obviously something that automates it would be a big help.

RBarryYoung
the theorem is right. However in the .Net world, linking is done dynamic and not a problem. It's the compilation step where this solution is needed.
Dykam
Sorry to fix you again :P. But the referencing(linking) at compile time happens in the .Net world, which is everything which is derived from that specific ECMA spec. Thus Mono, dotGnu and .Net. Not Windows itself.
Dykam
Heh, fair enough.
RBarryYoung
A: 

Probably they are not referenced at all. They may abstract each others code.

Emrah GOZCU
Check in Reflector (or look at the screenshot) : they clearly have hard-references to each other...
Thomas Levesque
Do you see any word saying the image taken by reflector in the message body?
Emrah GOZCU
I'll be one who says that. The symbols and way the tree is displayed is clearly the reflector.
Dykam
Ok i am done with this, just you should be knowing that, this is another way you probably used also, to get over this circular reference issue.It may help someone, it is not ignored answer at all.
Emrah GOZCU
Of course, it would be a sensible way of solving this issue... It's just not the way that was used here.
Thomas Levesque
+15  A: 

It can be done the way Dykam described but Visual Studio blocks you from doing it.

You'll have to use the command-line compiler csc.exe directly.

  1. csc /target:library ClassA.cs

  2. csc /target:library ClassB.cs /reference:ClassA.dll

  3. csc /target:library ClassA.cs ClassC.cs /reference:ClassB.dll


//ClassA.cs
namespace CircularA {
    public class ClassA {
    }
}


//ClassB.cs
using CircularA;
namespace CircularB {
    public class ClassB : ClassA  {
    }
}


//ClassC.cs
namespace CircularA {
    class ClassC : ClassB {
    }
}
Alfred Myers
You can do this in Visual studio too though it's quite harsh to too, the basic way is to use #if's and remove the reference using the solution explorer, reversing that in the third step. A other way i'm thinking of is a third project file including the same files but different references. This would work as you can specify the build order.
Dykam
As far as i know, can't test it here.
Dykam
I would really like to see that. From what I experimented here, the moment you try to Add Reference, the IDE stops you.
Alfred Myers
I know. But a third project not having that reference AND the #if symbol, and be referenced by the second, which is referenced by the first. No cycle. But the third uses the code of the first and outputs to the first assembly location. an assembly can easily be replaced by another with the same specs. But I think strongnaming can cause a problem in this method.
Dykam
It's a little like Srdjan's answer, though a different method.
Dykam
+19  A: 

RBarryYoung and Dykam are onto something. Microsoft uses internal tool which uses ILDASM to disassemble assemblies, strip all internal/private stuff and method bodies and recompile IL again (using ILASM) into what is called 'dehydrated assembly' or metadata assembly. This is done every time public interface of assembly is changed.

During the build, metadata assemblies are used instead of real ones. That way cycle is broken.

Srdjan Jovcic
Interesting answer, do you have any links?
Henk Holterman
I am trying to find external reference to the tool. I do not think it is published outside Microsoft, but concept is simple: disassemble-strip internals-reassemble.
Srdjan Jovcic
Agreed - interesting answer. Some links to back this up would be good.
Drew Noakes
Well, he is from Redmond, WA - according to his SO profile...
Ori Pessach
Yes, that's indeed the way it is done (from personal experience).
Pavel Minaev
If they would indeed strip all internal and private stuff, it would not be possible to decompile it, see what the private classes are, what others they reference etc. This is however very well possible with the exception of methods decorated with the attribute `MethodImpl(MethodImplOptions.InternalCall)`, which are only a few. Perhpaps I misunderstood your point. A link that backs up your story could be helpful, too.
Abel
True. We do not need internal and private stuff in assembly A to be able to reference its publics when compiling assembly B. You point about InternalCall methods stands, but is not relevant to this discussion. Sorry, but there is no link. In my knowledge, this is not documented publicly.
Srdjan Jovcic
But these are strongly signed assemblies. These dehydrated metadata-only assemblies would have a different cryptographic hashes. Perhaps the compiler doesn't check this, instead it's a runtime concept only. Or maybe it's a special compiler too.
Drew Noakes
They are not strongly signed until after build (they are delay signed), so dehydrated assemblies are not signed.
Srdjan Jovcic
+5  A: 

Its pretty easy to do in Visual Studio as long as you don't use project references... Try this:

  1. Open visual studio
  2. Create 2 Class Library projects "ClassLibrary1" & "ClassLibrary2".
  3. Build
  4. From ClassLibrary1 add a reference to ClassLibrary2 by browsing to the dll created in step 3.
  5. From ClassLibrary2 add a reference to ClassLibrary1 by browsing to the dll created in step 3.
  6. Build again (Note: if you make changes in both projects you would need to build twice to make both references "fresh")

So this is how you do it. But seriously... Don't you EVER do it in a real project! If you do, Santa wont bring you any presents this year.

JohannesH
A: 

Technically, it's possible that these were not compiled at all, and assembled by hand. These are low level libraries, after all.

tylermac
Not really. There isn't many low level stuff in it , only basic. What made you think it would be low level? The runtime and corlib is low level. Relatively. Still plain C or C++, thought the JIT contains low level stuff.
Dykam