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

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

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

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

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

Я надеюсь что помогает.

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

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

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

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

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

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

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

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

Я обычно предпочитаю избегать всего беспорядка 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.