Як Microsoft створила збірки, які мають кругові посилання?

У .NET BCL є кругові посилання між:

• System.dll і System.Xml.dll
• System.dll і System.Configuration.dll
• System.Xml.dll і System.Configuration.dll

Ось скріншот із .NET Reflector, який показує, що я маю на увазі:

Як Microsoft створила ці збірки, для мене загадка. Чи потрібен спеціальний процес компіляції, щоб це дозволити? Я думаю, що тут відбувається щось цікаве.

Я можу лише сказати, як це робить проект «Моно». Теорема досить проста, хоч і дає кодовий безлад.

Спочатку вони компілюють System.Configuration.dll, без частини, яка потребує посилання на System.Xml.dll. Після цього вони компілюють System.Xml.dll звичайним способом. Тепер настає магія. Вони перекомпілюють System.configuration.dll, при цьому частина потребує посилання на System.Xml.dll. Зараз є вдала компіляція з круговою посиланням.

Коротко:

• A складається без коду, що потребує B, і посилання на B.
• Б складено.
• A перекомпілюється.

RBarryYoung і Dykam знаходяться на чомусь. Корпорація Майкрософт використовує внутрішній інструмент, який використовує ILDASM для розбирання збірок, роздягання всіх внутрішніх / приватних речей та тіл методів та повторної перекомпіляції IL (за допомогою ILASM) у те, що називається «зневоднена збірка» або збірка метаданих. Це робиться щоразу, коли публічний інтерфейс складання змінюється.

Під час збирання використовуються збірки метаданих замість реальних. Таким чином цикл порушений.

Це можна зробити так, як описав Dykam, але Visual Studio заважає вам це робити.

Вам доведеться використовувати компілятор командного рядка csc.exe безпосередньо.

1. csc / target: бібліотека ClassA.cs

2. csc / target: бібліотека ClassB.cs /reference:ClassA.dll

3. csc / target: бібліотека 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 {
    }
}

У Visual Studio це зробити досить просто, доки ви не використовуєте посилання на проекти ... Спробуйте:

1. Відкрита візуальна студія
2. Створіть 2 бібліотечні проекти класів "ClassLibrary1" та "ClassLibrary2".
3. Побудувати
4. З ClassLibrary1 додайте посилання на ClassLibrary2, перейшовши на dll, створений на кроці 3.
5. З ClassLibrary2 додайте посилання на ClassLibrary1, перейшовши на dll, створений на кроці 3.
6. Збірка заново (Примітка: якщо ви внесете зміни в обидва проекти, вам потрібно буде скласти двічі, щоб зробити обидві посилання "свіжими")

Отже, це, як ви це робите. Але серйозно ... Хіба ви НІКОЛИ не зробите це в реальному проекті! Якщо ви це робите, Санта не буде приносити вам подарунків цього року.

Я думаю, це можна зробити, починаючи з ациклічного набору збірок і використовуючи ILMerge, щоб потім об'єднати менші збори в логічно пов'язані групи.

Ну, я ніколи не робив цього в Windows, але я робив це у багатьох середовищах компіляції-посилання-rtl, які слугували для нього практичними прародителями. Що ви робите, це спочатку зробити заглушку "target" без перехресних посилань, потім посилання, потім додайте кругові посилання, а потім повторно посилання. Зв'язки, як правило, не переймаються циркулярними пересиланнями або наступними ланцюжками відліку, вони дбають лише про те, щоб мати змогу вирішувати кожну посилання самостійно.

Тож якщо у вас є дві бібліотеки, A і B, на які потрібно посилатися одна на одну, спробуйте щось подібне:

1. Посилання А без жодних посилань на Б.
2. Посилання В з відкликами до А.
3. Посилання А, додаючи у відповідях на Б.

Dykam вказує на те, що це компіляція, а не посилання на .Net, але принцип залишається тим самим. Створіть свої перехресні посилання з експортованими вхідними точками, але з усіма, крім одного з них, які мають свої посилання на інші, затримані з. Побудуйте їх так. Потім розстебніть зовнішні посилання та відновіть їх. Це повинно працювати навіть без будь-яких спеціальних інструментів, насправді цей підхід працював на кожній операційній системі, на якій я коли-небудь пробував (близько 6 з них). Хоча, очевидно, щось, що автоматизує, було б великою допомогою.

Один з можливих підходів полягає у використанні умовної компіляції (#if) для сперші компіляції System.dll, яка не залежить від цих інших збірок, потім компіляції інших збірок і, нарешті, перекомпіляції System.dll для включення частин залежно від Xml та Конфігурація.

Технічно можливо, що вони зовсім не були складені, а зібрані вручну. Зрештою, це бібліотеки низького рівня.