Как вы можете централизовать конфигурацию в нескольких проектах?

У меня есть решение с примерно 10 проектами с конфигурацией только для чтения. Это веб-приложения, службы Windows, консольные приложения и т.д. Все проекты, кроме одного, находятся на одном сервере. Каждый проект имеет 3 среды - dev, test и production. Таким образом, существует 30 различных конфигураций, каждый из которых имеет достойное количество настроек. Это громоздко, чтобы поддерживать конфигурацию в каждом приложении и среде.

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

Как вы планируете централизовать конфигурацию для нескольких проектов?

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

Поскольку они (почти) все на одном сервере, вы можете рассмотреть возможность предоставления значений по умолчанию в machine.config и/или центральных файлах web.config. Я обычно не поклонник использования/изменения этого файла, но они есть... в \Windows\Micsrosoft.NET\Framework<version>\Config\