Плагин для использования собственного app.config

Question

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

Мое хостинговое приложение использует файл app.config для некоторых значений по умолчанию для исполняемой сборки (которая является службой Windows).

Каждый плагин должен иметь возможность загружать свои собственные настройки из отдельного файла настроек плагина, потому что хост не должен знать о настройках плагина. В проекте плагина я также добавил файл app.config (с некоторыми настройками и строкой соединения), чтобы я мог создать экземпляр класса Properties.Settings и использовать его свойства в коде плагина.

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

Есть ли способ загрузить настройки app.config в каждый плагин, чтобы сгенерированный класс Properties.Settings работал? Если нет, есть ли другой способ загрузить файл настроек на основе app.config в плагин? Я планирую добавить метод LoadConfiguration в интерфейс IPlugin, чтобы каждый плагин загружал свои собственные настройки.

Answer 1

Вы работаете против архитектуры app.config. Вы получаете один файл app.config на исполняемый файл (EXE, а не DLL). Исполняемый файл запускается, создает свой AppDomain, а затем загружает MyApp.exe.config. Вы можете добавить все объекты app.config в Visual Studio, но они игнорируются для библиотек DLL. Я думаю, что вы хотите сделать, это вручную скопировать XML из dll.config и вставить его в прикладной уровень app.config. (Я уверен, что есть способ автоматизировать это с помощью TeamBuild или чего-то подобного.) Переопределенные значения будут доступны для вашего класса Properties.Settings.

Answer 2

Я предпочитаю создавать и использовать плагин типа IConfigManager. Его задача - абстрагироваться от того, как хранится конфигурация. Вы получаете экземпляр этого через внедрение зависимости. Таким образом, реализация IConfigManager может загружать настройки из нескольких файлов .config, из сети, из БД или из любого другого источника. Я также использую его для предоставления значений по умолчанию на основе пользователя, машины и / или приложения - которые могут быть переопределены пользователем, например, цвет фона, шрифт и т. д.

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

Надеюсь, это поможет.

Answer 3

Хотелось бы что-то подобное ConfigurationManager.OpenMappedExeConfiguration ? Вы можете создать объект конфигурации, считывающий значения из определенного файла.

Answer 4

Вы можете заставить каждый плагин читать его собственный ConfigurationSection, а затем в главном файле конфигурации использовать настройку ConfigSource для указания на внешний файл. (См. Эту ссылку для получения дополнительной информации)

Вы не полностью избегаете наличия информации о конфигурации плагина в основном файле app.config, но, по крайней мере, специфические настройки плагина находятся в отдельных файлах.

Answer 5

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

В наших плагинах мы используем несколько экземпляров клиентов службы WCF. Отличительной особенностью этих сервисов является то, что они поставляются с разделами app.config, которые можно использовать для настройки поведения, типа обслуживания, безопасности и т. Д. И т. Д.

Теперь, когда мы загружаем наши плагины, эти разделы отсутствуют в конфигурации, и поэтому правильные конечные точки не могут быть найдены. Конечно, мы могли бы установить их в коде, но этот тип выбивает возможность устанавливать другие параметры конфигурации по мере необходимости. Мы могли бы хотеть реализовать ws-security, например.

Так что нам нужен способ загрузить эти конфиги, чтобы плагины могли прочитать там соответствующие настройки. Конечно, мы можем объединить все конфиги в один, но это исключает метод «просто плагин», так как вам придется управлять конфигами вместе с установкой плагина.

Я думал о создании небольшого инструмента, который бы объединял конфигурацию 'master' со всеми конфигами, помещенными в подкаталог проекта, и заменял файл .exe.config этим. Я думаю, что это сработает, но мне было интересно, если .NET не предоставляет лучшие варианты. Несколько доменов приложений - это не то, что должно работать, потому что плагины должны взаимодействовать (модель поставщика / потребителя) друг с другом, и мы не хотим переключаться на удаленное взаимодействие только из-за этой проблемы.

Обновление: я исправил большинство проблем с помощью ConfigurationManager, чтобы открыть существующие настройки для чтения настроек приложения. Что касается клиентов WCF; Вы можете загрузить конфигурацию конечной точки / привязки для сервера и клиента, как показано здесь: http://weblogs.asp.net/cibrax/archive/2007/10/19/loading-the-wcf-configuration-from-different-files-on-the-client-side.aspx

Answer 6

Я обычно предпочитаю избегать всей путаницы app.config, создавая выделенный XML-файл, который хост обрабатывает с настройками плагина также внутри. XML будет выглядеть примерно так:

<root>
    <Settings>
        Here's where anything specific to the app goes.
    </Settings>
    <plugins>
        <plugin type="mylibrary.myclass">
            Here I let the plugin serialize itself however it wants to.
        </plugin>
    </plugins>
</root>

Хостинговое приложение затем создает плагин из атрибута type и проверяет, реализует ли класс ISerializable ; если это произойдет, то плагин будет десериализовать себя. Немного страшно, чтобы плагины были встроены в настройки приложения, но если вы загрузите подстроку плагина Xml в новый XmlReader , вам не придется беспокоиться об ошибке чтения плагина. далеко в строке XML.