Возможно ли интернализировать классы DynamicProxy Castle Project с использованием ILMerge?

Question

У меня есть библиотека .NET, которая внутренне имеет зависимость от Castle.Core.dll, так как я использую Castle's DynamicProxy (в частности, «прокси-сервер без цели») для выполнения перехвата вызовов методов для пользовательской обработки. Поскольку моя сборка сильно названа, я хочу использовать ILMerge, чтобы объединить все мои зависимости в единую сборку для развертывания, интернализируя типы моих зависимостей, чтобы не подвергать их неоправданно моим потребителям. Это особенно важно для случая NuGet, где, если моя сборка сильно названа, мне нужно установить зависимости пакета для версии зависимостей или разрывов разрешения сборки, поскольку Castle.Core.dll также сильно именем. Обратите внимание, что выпуск моего проекта в виде сильно названной сборки - это функция, оцененная моими пользователями, поэтому удаление сильного имени не является вариантом.

Очевидно, DynamicProxy требует, чтобы некоторые из его классов были общедоступными для правильной работы. Нет проблем, я могу исключить определенные типы из интернализации ILMerge. Однако мои проблемы возникают, когда у меня есть пользователь, который ссылается на мою библиотеку, но также ссылается на Castle.Core.dll. Публичные типы теперь предоставляются двумя сборками, а ссылки на них неоднозначны.

Если я не интернализую Castle.Core.dll, используя ILMerge, отправляя его вместе со своей собственной сборкой, это конфликтует с версиями для версий моей версии и версий моих пользователей. Если я использую ILMerge для интернализации сборки, я вынужден исключить интернализацию типов, которые DynamicProxy требует для правильной работы. Этот подход разрушит любой проект, который ссылается как на мою сборку, так и на Castle.Core.dll из-за неоднозначных типов.

Я вынужден в один из этих двух субоптимальных курсов действий? Или есть какое-то решение, о котором я еще не думал?

Answer 1

Если у вас есть два полностью квалифицированных типа с одним и тем же именем, вы столкнетесь с проблемой двусмысленности. Это можно решить, используя extern alias.

По умолчанию все ссылочные сборки относятся к глобальному псевдониму, поэтому в сгенерированном коде вы увидите что-то вроде global::System.String. Я не могу сказать наверняка, как использовать псевдоним extern в ILMerge, но вы можете использовать его для устранения неоднозначности ссылочных ассемблеров. В любом случае вы можете указать свой « внутренний« Castle.Core.dll, чтобы быть псевдонимом как нечто вроде строк « castle» и удалить глобальный псевдоним из него. Недостатком является то, что вам придется изменить свой код, чтобы воспользоваться этим как таковым castle::Castle.Core.Interceptor.IInterceptor.

Вот хороший ресурс, который показывает вам больше информации, в том числе изображения: http://www.davidarno.org/c-howtos/aliases-overcoming-name-conflicts-part-2-extern-alias/

---

Имейте в виду, что вторичное ссылки Castle.Core.dll (другими, используя сборку) может содержать то же самое но по всем учетным записям они по-прежнему представляют собой два совершенно разных класса, то есть метод, который ожидает, что тип castle::Castle.Core.Interceptor.IInterceptor не будет работать, передав тип Castle.Core.Interceptor.IInterceptor со второй сборки.