Внедрить зависимости (NLog) в динамически загружаемые типы - PullRequest
Новая
       43

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

3 голосов
/ 30 ноября 2011

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

Первоначально я загружаю плагин через Assembly.LoadFrom(fi.FullName).GetTypes() и определяю необходимый тип с помощью (IPlugin)Activator.CreateInstance(type);.

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

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

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

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

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

Ответы [ 2 ]

2 голосов
/ 02 декабря 2011

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

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

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

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

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

1 голос
/ 30 ноября 2011

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

Это своего рода «хранилища регистрации компонентов»

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

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

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

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

Некоторые ключевые слова, которые могут помочь вамявляются "ServiceLocator" "MicroKernel" "Depency Injection"

Компоненты:

...