Jak firma Microsoft utworzyła zestawy, które mają odwołania cykliczne?

W .NET BCL istnieją cykliczne odwołania między:

• System.dll i System.Xml.dll
• System.dll i System.Configuration.dll
• System.Xml.dll i System.Configuration.dll

Oto zrzut ekranu z .NET Reflector, który pokazuje, o co mi chodzi:

Sposób, w jaki Microsoft stworzył te zestawy, jest dla mnie tajemnicą. Czy wymagany jest specjalny proces kompilacji, aby to umożliwić? Wyobrażam sobie, że dzieje się tu coś interesującego.

Mogę tylko powiedzieć, jak to robi Mono Project. Twierdzenie jest dość proste, chociaż powoduje bałagan w kodzie.

Najpierw kompilują System.Configuration.dll, a część nie wymaga odwołania do System.Xml.dll. Następnie kompilują System.Xml.dll w normalny sposób. Teraz jest magia. Ponownie kompilują System.configuration.dll, przy czym część wymaga odwołania do System.Xml.dll. Teraz jest pomyślna kompilacja z odwołaniem cyklicznym.

W skrócie:

• A jest kompilowany bez kodu wymagającego B i odwołania do B.
• B jest kompilowany.
• A jest ponownie kompilowany.

RBarryYoung i Dykam są na czymś. Firma Microsoft używa wewnętrznego narzędzia, które używa ILDASM do dezasemblacji złożeń, usuwania wszystkich wewnętrznych / prywatnych elementów i treści metod oraz ponownej kompilacji IL (przy użyciu ILASM) do tak zwanego „zestawu odwodnionego” lub zestawu metadanych. Odbywa się to za każdym razem, gdy zmienia się publiczny interfejs asemblera.

Podczas kompilacji używane są zestawy metadanych zamiast rzeczywistych. W ten sposób cykl jest przerwany.

Można to zrobić w sposób opisany przez Dykama, ale program Visual Studio uniemożliwia to.

Będziesz musiał bezpośrednio użyć kompilatora wiersza polecenia csc.exe.

1. csc / target: biblioteka 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 {
    }
}

Jest to całkiem łatwe do zrobienia w programie Visual Studio, o ile nie używasz odwołań do projektu ... Spróbuj tego:

1. Otwórz Visual Studio
2. Utwórz 2 projekty biblioteki klas „ClassLibrary1” i „ClassLibrary2”.
3. Budować
4. Z ClassLibrary1 Dodaj odwołanie do ClassLibrary2, przechodząc do biblioteki dll utworzonej w kroku 3.
5. Z ClassLibrary2 Dodaj odwołanie do ClassLibrary1, przechodząc do biblioteki dll utworzonej w kroku 3.
6. Utwórz ponownie (Uwaga: jeśli wprowadzisz zmiany w obu projektach, musisz zbudować dwukrotnie, aby oba odniesienia były „świeże”)

Więc tak to się robi. Ale poważnie ... Nie rób tego NIGDY w prawdziwym projekcie! Jeśli to zrobisz, Mikołaj nie przyniesie Ci w tym roku żadnych prezentów.

Myślę, że można to zrobić zaczynając od acyklicznego zestawu złożeń i używając ILMerge, aby następnie połączyć mniejsze zespoły w logicznie powiązane grupy.

Cóż, nigdy nie robiłem tego w systemie Windows, ale zrobiłem to na wielu środowiskach kompilacji-link-rtl, które służyły jako praktyczni przodkowie. Najpierw tworzysz pośredniczące „cele” bez odsyłaczy, a następnie łączysz, dodajesz odwołania cykliczne i ponownie łączysz. Linkery generalnie nie przejmują się cyklicznymi referencjami lub podążaniem za łańcuchami referencji, dbają tylko o możliwość samodzielnego rozwiązania każdego odwołania.

Więc jeśli masz dwie biblioteki, A i B, które muszą się odwoływać, spróbuj czegoś takiego:

1. Link A bez odwołań do B.
2. Link B z odwołaniami do A.
3. Link A, dodając odwołania do B.

Dykam ma rację, jest kompilowany, a nie linkowany w .Net, ale zasada pozostaje ta sama: twórz źródła z odsyłaczami z ich wyeksportowanymi punktami wejścia, ale wszystkie z nich oprócz jednego mają własne odniesienia do innych. na zewnątrz. Zbuduj je w ten sposób. Następnie usuń odnośniki zewnętrzne i odbuduj je. To powinno działać nawet bez żadnych specjalnych narzędzi, w rzeczywistości to podejście działało na każdym systemie operacyjnym, na którym kiedykolwiek próbowałem (około 6 z nich). Chociaż oczywiście coś, co automatyzuje, byłoby bardzo pomocne.

Jedną z możliwych metod jest użycie kompilacji warunkowej (#if), aby najpierw skompilować System.dll, który nie zależy od tych innych zestawów, następnie skompilować inne zestawy, a na końcu ponownie skompilować System.dll, aby uwzględnić części zależne od Xml i Konfiguracja.

Z technicznego punktu widzenia możliwe jest, że nie zostały one w ogóle skompilowane i złożone ręcznie. W końcu są to biblioteki niskiego poziomu.