AssemblyResolve для сборок GAC

Question

Я пытаюсь поместить свою сборку в GAC по соображениям производительности.У него есть некоторый код, который привязывается к событию AssemblyResolve.Однако после того, как GAC выполнил сборку, обработчик событий AssemblyResolve больше не срабатывает, когда источником разрешения является моя собственная сборка GAC.

Другими словами, моя сборка GAC имеетссылка на XYZ.dll.Вместо того, чтобы распространять его отдельно, в моей сборке GAC XYZ.dll хранится как встроенный ресурс, который загружается при запуске.Обработчик разрешения сборки возвращает динамически загруженный экземпляр XYZ.dll.Однако теперь, когда моя сборка GAC, событие AssemblyResolve вообще не запускается для XYZ.dll.

Я полагаю, это связано с тем, что контекст загрузки отличается ... но яЯ не уверен, как с этим бороться.Как я могу получить разрешение для работы теперь, когда моя сборка GAC'd?

Answer 1

Конечно, это не работает.GAC - это контрмер DLL Ад, он гарантирует, что любое приложение, которое опирается на конкретную версию DLL, получит конкретную версию DLL, которую они запрашивали.Последовательно, независимо от того, какой процесс попросил это.Если разрешить зависимости DLL-библиотеки GAC в пути прохождения процесса, это приведет к возвращению ада DLL в наихудший из возможных способов.Это полностью разрушает гарантию, которую предоставляет GAC, теперь DLL можно , а не доверять, чтобы она работала согласованно.

Это также не просто тонкий, в основном страшный сценарий, где базовый класспроизводный класс, определенный в сборке, которая является GAC-ed, определяется в зависимой сборке.То, на что вы надеетесь работать, позволит полностью реализовать различные базовые классы.Есть разумные шансы, что дрожание не упадет, если базовый класс не слишком отличается.Фактический результат во время выполнения довольно печален, неправильный код выполняется с несколькими способами, чтобы диагностировать почему, особенно для пользователя без отладчика.DLL Hell - это кошмар пользователя, человек, наименее способный диагностировать и устранить проблему, является жертвой.

CLR категорически отказывается разрешить вам стрелять так по ноге пользователя.Да, загрузка контекста - это ключ, Fusion - основной API.