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

Question

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

НО ....

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

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

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

Followup:

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

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

Дейв

Answer 1

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

---

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

<pages configSource="pages.config"/>

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

Answer 2

Мой предпочтительный метод - использовать 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 предоставляет отличную утилиту под названием «Проекты веб-развертывания», которая позволит вам легко управлять всем этим, нажмите здесь

Answer 3

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

Answer 4

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

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

Answer 5

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