При написании профилировщика clr вы можете загрузить вспомогательные dll с классами помощников.
Некоторые другие спрашивали об этом, поскольку это полезная стратегия, но ответы не касались многих проблем в этом решении, например:
Пример 1- CLR profiler: проблема с использованием DefineAssemblyRef
Пример 2- https://github.com/dotnet/coreclr/issues/3894 (фактическое решение не дано)
В целом, есть несколько вариантов, которые приходят на ум:
GAC - это правильное решение, но оно требует шага установки, и в некоторых средах GAC может отсутствовать (azure, linux [с .net core]).
Другой способ - ввести код, который выполняет AssemblyResolve + =
Напоминает то, что говорится в примере 1, но это приведет к проблемам, связанным с прозрачным кодом, вызывающим код + =, который является securityCritical и т. Д ...
Или другие проблемы, связанные с высокими / средними / ... уровнями доверия, реализованными, например, в IIS, которые могут затруднить загрузку этой вспомогательной библиотеки DLL (даже если она имеет строгое имя).
Другая большая проблема заключается в том, что вспомогательная dll будет загружена в определенный домен приложений, а не в «Реестр общих сборок EE». Это может вызвать проблемы в стратегии MultiDomainHost LoaderOptimization, если ссылки на dll внедряются в dll GAC, а appDomain, содержащий вспомогательный dll, отключается.
Итак, каков рекомендуемый способ загрузки dll-помощника из профилировщика clr без GAC и избежания всех этих проблем?