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

Question

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

НО ....

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

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

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

Followup:

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

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

Dave

Answer 1

Вы используете один мастер-файл конфигурации, который указывает на другие конфигурационные файлы. Here's an example of how to do this.

---

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

<pages configSource="pages.config"/> 

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

Answer 2

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

Answer 3

Отличный способ управления большими наборами конфигураций - создавать настраиваемые разделы конфигурации. Phil Haack обсуждает это очень хорошо в этой статье. Custom configuration sections in 3 easy steps

Answer 4

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

Answer 5

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

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