Inspecting System.Xml.dll reveals it references System..dll, inspecting System.dll reveals it references System.Xml.dll. As far as I know, it's not possible to create circular references. Is this a trick from Microsoft? If the two assemblies reference each other, why create two seperate ones?
5 Comments
Yes, I think it's a trick from Microsoft. I believe that they did it by
1. replacing the class in System.dll that that refer to classes in System.Xml.dll with blank class and then
2. removing the reference of System.Xml.dll from System.dll.
3. compiling System.dll. -> You will get System.dll that doesn't have System.Xml.dll reference.
4. compiling System.Xml.dll with the reference to System.dll -> You will get System.Xml.dll with the reference to System.dll
5. recompiling System.dll with the actual source code
I can't remember where I saw it from. I will give you a reference later.
Why bother creating two assemblies in the first place, especially if it is this difficult?
This makes sense. Thanks Nat.
I found an interesting thing. If you build up a circular reference assemblies once, you might not have to do that again.
For example, if you have System.dll and System.Xml.dll already and you want to modify one of that, all you have to do is to modify it and recompile against the older version of the other file. But keep in mind that you might need to recompile both of them once or twice to update both of them to be the same version (I mean assembly version attribute).
Either way, it definitely sucks that they are doing this. What an awkward design. Instead they should move the basic XmlReader stuff to System.dll (who wants to load all of System.Xml anyway). In Whidbey they even have Microsoft.JScript and Microsoft.Vsa dependencies on System. If they do 5 more of these things I'll start my own Framework that only depends on mscorlib :-)
