Объединение настраиваемых разделов конфигурации во время выполнения в .NET

Система конфигурации .NET не очень гибкая

Этот комментарий является точным и объясняет, почему вы так долго искали и еще ничего не нашли. Не все части .NET Framework "хороши", System.Configuration заслуживает места в самом низу. Он смехотворно перестроен для чего-то, что в конечном итоге является простой задачей, но в то же время превратилось в нечто чрезвычайно негибкое. Трудно реконструировать, как это произошло, я думаю, что все было парализовано соображениями безопасности. Возможно, в некоторой степени понятно, что использование данных в программе всегда сопряжено с серьезным риском.

Единственная точка расширения, о которой я знаю, - это написание собственного SettingsProvider. Фреймворк имеет только один для общего использования - класс LocalFileSettingProvider. Также чрезвычайно негибкий, нет никакого способа изменить его поведение. Существует достойный пример для поставщика настраиваемых параметров: Образец RegistrySettingsProvider демонстрирует поставщика, который хранит настройки в реестре. Это может быть хорошей отправной точкой для написания собственного.

Не совсем то, что вы имеете в виду, возможно, не стоит забывать о том, что вы можете разбить слои внутри System.Configuration.

Как указано в silver, хорошо сконфигурированный ExeConfigurationFileMap может справиться с этой задачей при определенной стоимости.

Я взял его пример и сделал его рабочую версию.

Вот два файла конфигурации, которые я объединил для своих тестовых целей:

custom.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="custom" type="..." />
  </configSections>
  <custom>
    <singleProperty id="main" value="BaseValue" />
    <propertyCollection>
      <property id="1" value="One" />
      <property id="4" value="Four" />
    </propertyCollection>
  </custom>
</configuration>

app.config

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="custom" type="..."/>
  </configSections>
  <custom>
    <singleProperty id="main" value="OverriddenValue" />
    <propertyCollection>
      <property id="1" value="OverridenOne" />
      <property id="2" value="Two" />
      <property id="3" value="Three" />
    </propertyCollection>
  </custom>
</configuration>

И я использовал следующий код для проверки объединенной настройки:

var map = new ExeConfigurationFileMap();
map.MachineConfigFilename = PathToCustomConfig;
map.ExeConfigFilename = PathToAppConfig;
                
var configuration = ConfigurationManager.OpenMappedExeConfiguration(
        map, 
        ConfigurationUserLevel.None);
var section = configuration.GetSection("custom") as CustomConfigSection;
Assert.IsNotNull(section);

Assert.AreEqual(section.SingleProperty.Value, "OverriddenValue");
Assert.AreEqual(section.PropertyCollection.Count, 4);
// Needed to map the properties as dictionary, not to rely on the property order
var values = section.PropertyCollection
        .Cast<SimpleConfigElement>()
        .ToDictionary(x => x.ID, x => x.Value);
Assert.AreEqual(values["1"], "OverridenOne");
Assert.AreEqual(values["2"], "Two");
Assert.AreEqual(values["3"], "Three");
Assert.AreEqual(values["4"], "Four");

плюсы этого подхода

• Я заставляю работать встроенную логику слияния
• Работает для более старых версий .NET (проверено на 3.5)
• Нет необходимости в отражении или другой черной магии, чтобы вызвать такое поведение.

минусы

• Не очень уверен, но, устанавливая map.MachineConfigFilename = PathToCustomConfig;, я предполагаю, что удаляю все значения, которые установлены настоящим machine.config файлом. Это может быть подвержено ошибкам, и этого следует избегать для веб-приложений, поскольку большинство из них полагаются на то, что находится на самом деле machine.config
• Необходимо передать расположение файла конфигурации приложения, так как оно больше не определяется автоматически. Таким образом, необходимо выяснить, как будет называться app.config при компиляции кода (обычно AssemblyName.exe.config)
• Таким образом можно объединить содержимое только двух файлов. Если нужна более крупная иерархия, это не сработает.

Я все еще нахожусь в процессе доработки техники, поэтому я вернусь, чтобы обновить этот пост, как только закончу.

По умолчанию существует 3 уровня наследования конфигурации: Machine, Exe и User (которые могут быть Roaming или Local). Если вы загружаете файлы конфигурации самостоятельно, вы можете использовать ExeConfigurationFileMap в сочетании с ConfigurationManager.OpenMappedExeConfiguration, чтобы загрузить собственную иерархию пользовательской конфигурации.

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

Если вы ознакомитесь с ответом на Как читать configSections, он включает некоторые примечания по определению, на каком уровне разделы были объявлены в иерархии (с помощью SectionInformation)

var localSections = cfg.Sections.Cast<ConfigurationSection>()
       .Where(s => s.SectionInformation.IsDeclared);