Как вы управляете файлами .NET app.config для больших приложений?

Предположим, что большое составное приложение построено на нескольких базовых компонентах, упакованных в свои собственные сборки: (чтение базы данных, обработчики протоколов и т. Д.). Для некоторых развертываний это может включать более 20 сборок. Каждая из этих сборок имеет настройки или информацию о конфигурации. Нашей команде нравится редактор настроек VS (и простой в использовании код, который он генерирует!), И различие между приложением и пользователем удовлетворяет большинство наших потребностей.

НО....

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

Microsoft EntLib решает эту проблему с помощью внешнего инструмента для создания файла .config монстра, но это также кажется клунным.

Какие методы вы используете для управления большими файлами .NET .config с разделами из нескольких общих сборок? Какой-то механизм включения? Пользовательские настройки ридеров?

СЛЕДОВАТЬ ЗА:

Ответ Уилла был именно тем, на что я намекал, и выглядит элегантно для секций плоской пары ключ / значение. Есть ли способ объединить этот подход с пользовательскими разделами конфигурации ?

Спасибо также за предложения по управлению различными .configs для разных целей сборки. Это также весьма полезно.

Дейв

18.09.2008 01:40:40
5 ОТВЕТОВ
РЕШЕНИЕ

Вы используете один главный файл конфигурации, который указывает на другие файлы конфигурации. Вот пример того, как это сделать.


Если ссылка не работает, вы указываете configSource для определенного раздела конфигурации. Это позволяет вам определить этот конкретный раздел в отдельном файле.

<pages configSource="pages.config"/>

что подразумевает, что в том же каталоге есть файл с именем "pages.config", содержащий все <pages />дерево узлов.

20
5.10.2011 14:47:47

Мы создали класс AssemblySettingsConfig, который действует как ConfigurationManager, но загружает .config для каждой отдельной сборки. Таким образом, у приложения есть файл .config, и любые библиотеки DLL, на которые оно ссылается, имеют свои собственные файлы .config. До сих пор хорошо сработало.

1
18.09.2008 02:36:26

Отличным способом управления большими наборами конфигурации является создание пользовательских разделов конфигурации. Фил Хаак очень хорошо обсуждает это в этой статье. Пользовательские разделы конфигурации за 3 простых шага.

4
5.10.2011 14:42:27

Мой предпочтительный метод - использовать MSBuild, если вы щелкнете правой кнопкой мыши по проекту и нажмете «выгрузить», появится новое меню с надписью «изменить». Выберите его, и он откроет файл проекта, чтобы вы могли его редактировать, прокручивайте вниз, пока не найдете закомментированный раздел, который называется «AfterBuild».

Затем вы можете добавить что-то вроде:

<Target Name="AfterBuild">
    <Delete Files="$(TargetDir)$(TargetFileName).config" />
    <Copy SourceFiles="$(ProjectDir)$(Configuration).config" DestinationFiles="$(TargetDir)$(TargetFileName).config" />
</Target>

Это заменит конфигурацию приложения с именем [Release | Debug] app.exe.config. Таким образом, вы можете поддерживать отдельные конфигурации в зависимости от того, как проект построен.

Но быстрый и грязный вариант (если вы не хотите играть с msbuild) состоит в том, чтобы просто поддерживать отдельные файлы конфигурации и затем определить, какой из них вы хотите включить, например так:

<appSettings configSource="Config\appSettingsDebug.config"/>
<roleManager configSource="Config\roleManagerDebug.config"/>

И если вы работаете с приложением asp.net, Microsoft предоставляет отличную утилиту под названием «Проекты веб-развертывания», которая позволит вам легко управлять всем этим, нажмите здесь

9
18.09.2008 04:46:40
Для тех, кто использует ClickOnce: По моему опыту, это решение (хотя и хорошее) не работает вместе с ClickOnce.
stakx - no longer contributing 8.05.2015 16:17:47

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

У ScottGu есть хороший пост об этом, и он прекрасно работает. Единственное, что у нас есть, это то, что нам нужно убедиться, что файлы конфигурации (web.config) извлекаются для редактирования из TFS перед каждой сборкой, чтобы их можно было скопировать.

2
18.09.2008 07:19:48