Nano Hash - криптовалюты, майнинг, программирование

Внедрение зависимостей (NLog) в динамически загружаемые типы

У меня есть своего рода архитектура плагина в моем решении. Есть известная папка, куда в нее класть плагины. Плагины реализуют интерфейс, который используется в основном проекте.

Изначально я загружаю плагин через Assembly.LoadFrom(fi.FullName).GetTypes() и создаю экземпляр нужного типа через (IPlugin)Activator.CreateInstance(type);.

Таким образом, хост (основное приложение) может выполнять соответствующий код, реализованный сборкой плагина. Пока это работает нормально.

Но недавно я попытался реализовать ведение журнала приложений через NLog и настроил NLog в хост-проекте, и это отлично сработало.

Проблема в том, что я хотел бы использовать (уже настроенный) регистратор в сборке плагина. Если я просто сошлюсь на NLog и использую его LogManager.GetCurrentClassLogger();, похоже, не будет задана конфигурация. Он не регистрируется в файлах, которые я настроил в хост-проекте из сборки плагина.

Я подумал о попытке внедрить экземпляр NLogger (созданный в хост-проекте) в свойство типа плагина.

Возможно ли это или есть предпочтительный способ выполнить такие вещи? Спасибо

dependency-injection dynamic c# nlog plugin-architecture
30.11.2011

Ответы:


1

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

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

Я не думаю, что контейнер IOC поможет вам в случае динамически загружаемых плагинов - контейнер не будет знать о них, поэтому вам придется изменить способ загрузки и настройки плагинов. И imho использование IOC для настройки nlog не лучшая идея.

Если предыдущие варианты не работают, вы можете попробовать изменить путь проверки сборки в app.config, чтобы ваши плагины загружались в домен по умолчанию — тогда NLog должен работать для этих плагинов (по крайней мере, работает для меня):

<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
  <probing privatePath="Plugins" />
</assemblyBinding>

02.12.2011
  • Использование IoC — хорошая идея, если в него уже встроена поддержка, такая как средства ведения журналов Ninject или Castle.Windsor. 02.12.2011
  • Но я предполагаю, что у автора уже есть зависимость от NLog в его компонентах (его плагины уже используют NLog для ведения журнала), поэтому внешнее внедрение nlog не требуется. Нужна единая конфигурация nlog, работающая как для приложения, так и для его плагинов. 02.12.2011
  • Да, эту проблему не решает IoC. Я также ожидаю, что он будет просто работать, как описано в вашем ответе. Единственное, с чем я не согласен, это imho, использование IOC для настройки nlog не является хорошей идеей, если только под настройкой вы не подразумеваете настройку прослушивателей/вывода и т. д., а не настройку самих классов регистратора. IoC отлично подходит для подключения классов логгеров. Как вы заметили, это не обязательно, но может быть полезно. 02.12.2011

    • 2

    Взгляните на контейнеры внедрения зависимостей, такие как Unity или Lightcore.

    Это какие-то "магазины регистрации компонентов"

    там вы можете зарегистрировать компоненты для интерфейсов. Тогда вашим потребителям просто нужно запросить интерфейс.

    Отображение интерфейс-компонент может быть сделано в конфигурационных файлах или исходном коде.

    Таким образом, вы можете изменить сопоставление без каких-либо проблем.

    Например, когда они создают новые экземпляры и у вас есть сложные типы в качестве параметров ctor, они могут выполнить автоматический поиск, если эти компоненты зарегистрированы, а затем автоматически внедрить их.

    Некоторые ключевые слова, которые могут вам помочь: «ServiceLocator», «MicroKernel», «Injection Depency».

    Составные части:

    • Лайткор
    • Unity
    • Также более ориентированным на плагины способом является MEF.
    30.11.2011
  • Предположим, я разрешаю плагин с помощью контейнера DI. Самому плагину нужен экземпляр логгера (уже настроенный в хост-системе, куда записывать файлы и так далее). Как это будет работать с NLog? Могу ли я внедрить регистратор как уже настроенный? 30.11.2011
  • Я не уверен, что понимаю вас, но вы также можете зарегистрировать живые экземпляры для некоторых типов. Например, вы создаете Loggerinstance и регистрируете его для ILogAdapter. Кстати, при использовании контейнера Di вы должны взглянуть на CommonServiceLocator, чтобы вы могли изменить Dic, не меняя свой код. 07.12.2011
    • Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..