Лучший способ обработки нескольких экземпляров файла конфигурации?

Question

Мы запускаем сложную систему, написанную на C# .NET 3.5, состоящую из 20 + сайтов, 10 + оконных служб и различных запланированных задач и вспомогательных приложений.

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

Мы не регистрируем наши DLL в GAC по различным причинам: 1) Нам нравится гибкость быстрого развертывания изменений в выборочных проектах без восстановления всей системы или возникновения ненужного времени простоя. 2) Некоторые экземпляры DLL требуют немного разных конфигураций; например, в некоторых проектах используются разные строки подключения, адреса электронной почты для уведомлений и т. д.

Мы экспериментировали с атрибутами файла AppSettings/configSource в Web.config/App.config, но они работают только с относительными путями, а не с проектами. Мы рассмотрели вопрос о сохранении значений по умолчанию в machine.config, но это миссия, слишком запутанная и наполненная важными вещами, не связанными с нашими проектами.

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

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

Есть ли предлагаемый стандартный способ решения этой проблемы в .NET?

Answer 1

Если это все в одной компании, почему бы вам просто не хранить конфиги в базе данных? Я считаю, что в Enterprise Framework даже есть адаптеры, которые вы можете подключить, чтобы сделать именно это.

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

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

Итак, я думаю, что я говорю, если они все находятся в одной и той же компании/сфере влияния, так что вы можете использовать базу данных, которая является центральной для них, просто используйте БД.

Не оглашать реестр.

Answer 2

Я бы использовал OpenExeConfiguration (http://msdn.microsoft.com/en-us/library/ms224437.aspx), и каждое приложение/dll откроет 2 конфигурации, первое будет по умолчанию, второе - переопределяет.

Вы можете сохранить настройки по умолчанию в этом «центральном» местоположении, предоставляя доступ для чтения ко всем своим приложениям, а локальные конфигурации находятся рядом с вашими приложениями.

Answer 3

Как вы использовали эти веб-сайты и приложения, были ли эти модули в вашей системе запущены на одном компьютере и были ли эти модули вызывать библиотеки DLL из определенного каталога?

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

Если вам просто нужно переопределить какой-либо раздел конфигурации в общий файл конфигурации, вы можете сначала загрузить свои значения по умолчанию из централизованного расположения и загрузить свою конкретную конфигурацию в каждом проекте, а затем изменить объект конфигурации во время выполнения.