Comment Microsoft a-t-il créé des assemblys avec des références circulaires?

Dans le .NET BCL, il existe des références circulaires entre:

• System.dll et System.Xml.dll
• System.dll et System.Configuration.dll
• System.Xml.dll et System.Configuration.dll

Voici une capture d'écran de .NET Reflector qui montre ce que je veux dire:

La façon dont Microsoft a créé ces assemblages est un mystère pour moi. Un processus de compilation spécial est-il nécessaire pour permettre cela? J'imagine que quelque chose d'intéressant se passe ici.

Je peux seulement dire comment le projet Mono fait cela. Le théorème est assez simple, bien qu'il donne un désordre de code.

Ils compilent d'abord System.Configuration.dll, sans que la partie ait besoin de la référence à System.Xml.dll. Après cela, ils compilent System.Xml.dll de la manière normale. Maintenant vient la magie. Ils recompilent System.configuration.dll, la partie nécessitant la référence à System.Xml.dll. Maintenant, il y a une compilation réussie avec la référence circulaire.

En bref:

• A est compilé sans que le code ait besoin de B et de la référence à B.
• B est compilé.
• A est recompilé.

RBarryYoung et Dykam sont sur quelque chose. Microsoft utilise un outil interne qui utilise ILDASM pour désassembler les assemblys, dépouiller tous les éléments internes / privés et les corps de méthode et recompiler IL à nouveau (en utilisant ILASM) dans ce que l'on appelle un `` assemblage déshydraté '' ou un assemblage de métadonnées. Ceci est fait à chaque fois que l'interface publique de l'assembly est modifiée.

Pendant la génération, les assemblys de métadonnées sont utilisés au lieu des vrais. De cette façon, le cycle est rompu.

Cela peut être fait de la manière décrite par Dykam, mais Visual Studio vous empêche de le faire.

Vous devrez utiliser directement le compilateur de ligne de commande csc.exe.

1. csc / target: bibliothèque ClassA.cs

2. csc / target: bibliothèque ClassB.cs /reference:ClassA.dll

3. csc / target: bibliothèque 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 {
    }
}

C'est assez facile à faire dans Visual Studio tant que vous n'utilisez pas de références de projet ... Essayez ceci:

1. Ouvrir un studio visuel
2. Créez 2 projets de bibliothèque de classes "ClassLibrary1" et "ClassLibrary2".
3. Construire
4. À partir de ClassLibrary1, ajoutez une référence à ClassLibrary2 en accédant à la DLL créée à l'étape 3.
5. À partir de ClassLibrary2, ajoutez une référence à ClassLibrary1 en accédant à la DLL créée à l'étape 3.
6. Reconstruire (Remarque: si vous apportez des modifications dans les deux projets, vous devrez créer deux fois pour rendre les deux références "fraîches")

Voilà donc comment vous procédez. Mais sérieusement ... Ne le faites JAMAIS dans un vrai projet! Si vous le faites, le Père Noël ne vous apportera aucun cadeau cette année.

Je suppose que cela pourrait être fait en commençant par un ensemble acyclique d'assemblages et en utilisant ILMerge pour ensuite fusionner les petits assemblages en groupes logiquement liés.

Eh bien, je ne l'ai jamais fait sur Windows, mais je l'ai fait sur de nombreux environnements compile-link-rtl qui ont servi de progéniteurs pratiques pour cela. Ce que vous faites est d'abord de créer des "cibles" de stub sans les références croisées, puis de les lier, puis d'ajouter les références circulaires, puis de les relier. Les linkers ne se soucient généralement pas des références circulaires ou des chaînes de références suivantes, ils se soucient uniquement de pouvoir résoudre chaque référence par elle-même.

Donc, si vous avez deux bibliothèques, A et B qui doivent se référencer, essayez quelque chose comme ceci:

1. Reliez A sans aucune référence à B.
2. Lien B avec les références à A.
3. Lien A, en ajoutant les références à B.

Dykam fait un bon point, c'est compiler, pas lier en .Net, mais le principe reste le même: faites vos sources croisées, avec leurs points d'entrée exportés, mais avec tous sauf un ayant leurs propres références aux autres en dehors. Construisez-les comme ça. Ensuite, supprimez les références externes et reconstruisez-les. Cela devrait fonctionner même sans outils spéciaux, en fait, cette approche a fonctionné sur tous les systèmes d'exploitation sur lesquels je l'ai essayé (environ 6 d'entre eux). Bien que de toute évidence, quelque chose qui automatise ce serait d'une grande aide.

Une approche possible consiste à utiliser la compilation conditionnelle (#if) pour d'abord compiler un System.dll qui ne dépend pas de ces autres assemblys, puis compiler les autres assemblys, et enfin recompiler System.dll pour inclure les parties dépendant de Xml et Configuration.

Techniquement, il est possible que ceux-ci n'aient pas du tout été compilés et assemblés à la main. Ce sont des bibliothèques de bas niveau, après tout.