Предположим, что большое составное приложение построено на нескольких базовых компонентах, упакованных в их собственные сборки: (чтение базы данных, обработчики протоколов и т.д.). Для некоторых развертываний это может включать более 20 сборок. Каждая из этих сборок имеет настройки или информацию о конфигурации. Наша команда, как правило, любит редактор настроек VS (и простой в использовании код, который он генерирует!), А различие между приложениями и пользователями отвечает большинству наших потребностей.
НО....
Очень утомительно копировать и вставлять многие разделы конфигурации в наше приложение .xml. Кроме того, для общих компонентов, которые имеют одинаковые конфигурации для разных приложений, это означает, что нам нужно поддерживать повторяющиеся настройки в нескольких файлах .config.
Microsoft EntLib решает эту проблему с помощью внешнего инструмента для создания файла monster.config, но это также чувствует klunky.
Какие методы вы используете для управления большими файлами .NET.config с разделами из нескольких общих сборок? Какой-то механизм включения? Пользовательские читатели конфигурации?
Followup:
Ответ был именно тем, что я получал, и выглядит элегантно для плоских разделов пары ключ/значение. Есть ли способ объединить этот подход с настраиваемыми разделами конфигурации?
Спасибо также за предложения по управлению различными .configs для разных целей сборки. Это также весьма полезно.
Дейв
Вы используете один главный файл конфигурации, который указывает на другие файлы конфигурации. Вот пример того, как это сделать.
В случае, если ссылка гниет, то вы укажете configSource для определенного раздела конфигурации. Это позволяет определить этот конкретный раздел в отдельном файле.
<pages configSource="pages.config"/>
что означает, что в том же каталоге есть файл под названием "pages.config", который содержит полное дерево <pages /> node.
Мой предпочтительный метод - использовать 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 предоставляет отличную утилиту под названием "Проекты веб-развертывания", которая позволит вам легко справиться с этим, нажмите здесь
Отличным способом управления большими наборами настроек является создание настраиваемых разделов конфигурации. Phil Haack обсуждает это очень хорошо в этой статье Пользовательские разделы конфигурации в 3 простых шага
Настройте конфигурацию сборки для каждой среды развертывания/тестирования и используйте отдельные файлы конфигурации на основе каждой конфигурации сборки.
ScottGu имеет хороший пост об этом, и он отлично работает. Единственное, что у нас есть, это то, что мы должны убедиться, что файлы конфигурации (web.config) выгружены для редактирования из TFS перед каждой сборкой, чтобы можно было скопировать ее.
Мы создали класс AssemblySettingsConfig, который работает как ConfigurationManager, но загружает .config для каждой отдельной сборки. Таким образом, приложение имеет .config, и любые DLL файлы, на которые ссылаются, имеют свои .config файлы. До сих пор хорошо работает.