Можно ли использовать Assembly.ReflectionOnlyLoad вместе с политиками издателя / версией сборки?

Question

Моя цель:

Мы разрешаем интегрировать наш продукт со сторонними компонентами (библиотеками), которые не установлены как часть нашего продукта из-за лицензирования.В настоящий момент мы хотим загружать функции, относящиеся к сторонним компонентам, только если эти компоненты установлены на клиентском компьютере.

Текущее решение:

Я использую Assembly.ReflectionOnlyLoad с предоставлением полных именсторонних сборок для проверки правильности установки сторонних компонентов до того, как приложение загрузит соответствующие функции.Это работает для следующих сценариев:

• Точные версии библиотек установлены в GAC
• Точные версии библиотек копируются в каталог приложений / пути зондирования

Проблема:

Теперь мне нужно изменить решение для поддержки политик издателя (перенаправить привязку сборки к новой версии).Я только что протестировал свой код, и похоже, что ReflectionOnlyLoad игнорирует политику издателя, развернутую в GAC, поэтому мой механизм не будет загружать ожидаемые функции, даже если сборки сторонних производителей установлены правильно (новая версия с перенаправлением сборки).

Если я удалю свою проверку (= функции будут загружаться каждый раз), приложение будет корректно загружать новую версию сторонних сборок, поэтому политика издателя будет работать правильно, поскольку функции по-прежнему компилируются с зависимостью от старой версии.

Как проверить наличие сборки как в GAC, так и в путях проверки при использовании управления версиями и перенаправления сборки?

Answer 1

Кажется, вы можете вызвать AppDomain.ApplyPolicy , чтобы применить политики к имени сборки. Затем вы можете позвонить ReflectionOnlyLoad() по возвращенному имени.

Answer 2

Вы не можете использовать только ReflectionOnlyLoad.

Вся цель ReflectionOnlyLoad и его друзей в том, чтобы иметь возможность проверять метаданные сборки без учета политики и управления версиями.

Цзюньфэн Чжан объясняет это в своем исследовании ReflectionOnlyLoad методов .

Я подозреваю, что если вы хотите применить политику к загрузке, вам нужно будет загрузить сборки в отдельный домен приложений и обсудить их там. Преимущество этого подхода заключается в том, что вы сможете выгрузить AppDomain, который вы используете для размышлений и проверки. Недостатком является значительная сложность. Однако я не вижу большой альтернативы.

После того, как у вас есть отдельный AppDomain, вам понадобится класс MarshalByRefObject, чтобы вы могли выполнять проверку на удаленном AppDomain от вашего основного. Этот класс может быть загружен в удаленный AppDomain, а также делать любые вызовы Assembly.Load, отслеживая результаты. Когда это сделано, вы возвращаете какой-то отчет вызывающему абоненту в главном AppDomain. Наконец, вы можете выгрузить пульт дистанционного управления AppDomain. Загруженные вами типы не будут загружены в основной файл AppDomain.