In che modo Microsoft ha creato assembly con riferimenti circolari?

In .NET BCL ci sono riferimenti circolari tra:

• System.dll e System.Xml.dll
• System.dll e System.Configuration.dll
• System.Xml.dll e System.Configuration.dll

Ecco uno screenshot di .NET Reflector che mostra cosa intendo:

Il modo in cui Microsoft ha creato questi assembly è un mistero per me. È necessario un processo di compilazione speciale per consentirlo? Immagino che qui stia succedendo qualcosa di interessante.

Posso solo dire come fa il Mono Project. Il teorema è abbastanza semplice, sebbene dia un pasticcio di codice.

Per prima cosa compilano System.Configuration.dll, senza che la parte richieda il riferimento a System.Xml.dll. Dopo questo, compilano System.Xml.dll nel modo normale. Adesso arriva la magia. Ricompilano System.configuration.dll, con la parte che richiede il riferimento a System.Xml.dll. Ora c'è una compilazione di successo con il riferimento circolare.

In breve:

• A viene compilato senza che il codice richieda B e il riferimento a B.
• B è compilato.
• A viene ricompilato.

RBarryYoung e Dykam stanno pensando a qualcosa. Microsoft utilizza uno strumento interno che utilizza ILDASM per disassemblare gli assembly, rimuovere tutti gli elementi interni / privati ​​e i corpi dei metodi e ricompilare nuovamente IL (utilizzando ILASM) in quello che viene chiamato "assembly disidratato" o assembly di metadati. Questa operazione viene eseguita ogni volta che viene modificata l'interfaccia pubblica dell'assembly.

Durante la compilazione, vengono usati gli assembly di metadati anziché quelli reali. In questo modo il ciclo si interrompe.

Può essere fatto nel modo descritto da Dykam, ma Visual Studio ti impedisce di farlo.

Dovrai utilizzare direttamente il compilatore della riga di comando csc.exe.

1. csc / target: libreria ClassA.cs

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

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

È abbastanza facile da fare in Visual Studio fintanto che non usi riferimenti al progetto ... Prova questo:

1. Apri Visual Studio
2. Creare 2 progetti di libreria di classi "ClassLibrary1" e "ClassLibrary2".
3. Costruire
4. Da ClassLibrary1 aggiungere un riferimento a ClassLibrary2 sfogliando la dll creata nel passaggio 3.
5. Da ClassLibrary2 aggiungere un riferimento a ClassLibrary1 sfogliando la dll creata nel passaggio 3.
6. Crea di nuovo (Nota: se apporti modifiche in entrambi i progetti, dovrai compilare due volte per rendere entrambi i riferimenti "freschi")

Quindi è così che lo fai. Ma seriamente ... non farlo MAI in un progetto reale! Se lo fai, Babbo Natale non ti porterà nessun regalo quest'anno.

Immagino che potrebbe essere fatto iniziando con un insieme aciclico di assembly e utilizzando ILMerge per poi unire gli assembly più piccoli in gruppi logicamente correlati.

Beh, non l'ho mai fatto su Windows, ma l'ho fatto su molti ambienti compile-link-rtl che sono serviti come pratici progenitori per questo. Quello che devi fare è prima creare "target" stub senza i riferimenti incrociati, quindi collegare, quindi aggiungere i riferimenti circolari, quindi ricollegare. I linker generalmente non si preoccupano dei riferimenti circolari o delle seguenti catene di riferimenti, si preoccupano solo di essere in grado di risolvere ogni riferimento da soli.

Quindi, se hai due librerie, A e B che devono fare riferimento l'una all'altra, prova qualcosa del genere:

1. Collega A senza riferimenti a B.
2. Collega B con riferimenti ad A.
3. Link A, aggiungendo i riferimenti a B.

Dykam è un buon punto, è compilare, non collegare in .Net, ma il principio rimane lo stesso: crea le tue fonti con riferimenti incrociati, con i loro punti di ingresso esportati, ma con tutti tranne uno che hanno i propri riferimenti agli altri stubbed su. Costruiscili così. Quindi, elimina i riferimenti esterni e ricostruiscili. Questo dovrebbe funzionare anche senza strumenti speciali, infatti, questo approccio ha funzionato su tutti i sistemi operativi su cui l'ho provato (circa 6 di loro). Anche se ovviamente qualcosa che lo automatizza sarebbe di grande aiuto.

Un possibile approccio è utilizzare la compilazione condizionale (#if) per compilare prima un System.dll che non dipende da quegli altri assembly, quindi compilare gli altri assembly e infine ricompilare System.dll per includere le parti che dipendono da Xml e Configurazione.

Tecnicamente, è possibile che questi non siano stati compilati affatto e assemblati a mano. Queste sono biblioteche di basso livello, dopotutto.