How did Microsoft create assemblies that have circular references?

In the .NET BCL there are circular references between:

• System.dll and System.Xml.dll
• System.dll and System.Configuration.dll
• System.Xml.dll and System.Configuration.dll

Here's a screenshot from .NET Reflector that shows what I mean:

How Microsoft created these assemblies is a mystery to me. Is a special compilation process required to allow this? I imagine something interesting is going on here.

Solution 1:

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.

Solution 2:

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.

Solution 3:

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 {
    }
}

Solution 4:

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.

Solution 5:

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.