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

Question

У нашей компании есть несколько приложений - как веб-, так и консольных / windows - все они подключаются к одному и тому же набору баз данных. Я пытаюсь найти наилучший способ хранения / доступа / управления различными строками подключения к базе данных, чтобы их можно было использовать во всех приложениях.

В настоящее время у нас есть строки подключения в файлах machine.config на всех наших серверах. Хотя это устраняет необходимость иметь эти строки подключения в конфигурационном файле каждого приложения, мы все равно должны иметь один и тот же блок настроек на каждом сервере, и у каждого сервера есть 4 разные версии, в которые мы должны включить их (32- / 64-битные , 2.0 и 4.0 фреймворки). Кроме того, каждый сервер имеет свою собственную среду (dev, QA, production), поэтому эти параметры должны храниться отдельно. Это складывается, и становится трудно управлять, когда необходимы изменения.

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

файл configSource и appSettings

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

linkedConfiguration

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

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

Заранее спасибо.

Answer 1

Исходя из этого поста, это невозможно.

http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/1cad3740-12f5-4859-ba02-717c4b418a8c/

It must refer to a file in the same directory or in a subdirectory as the configuration file.

Теперь, если вы хотите исследовать версию конфигурации "прицеп для трактора", пройдите по этой кроличьей норе:

http://msdn.microsoft.com/en-US/vstudio/bb499684.aspx

Служба конфигурации

или (то же самое, но другой способ поиска) Google или Bing это

stocktrader msdn "Служба конфигурации"

Это не для слабонервных. Но это все о развертывании изменений конфигурации в больших средах.

Answer 2

Надеюсь, это поможет, хотя это может не совпадать с заданным вопросом.

Для управления конфигурациями в различных средах мы использовали очень хороший подход, в котором использовались такие инструменты автоматизации сборки, как maven и Jenkins,простая java-программа вместе с некоторыми скриптами bash.

Мы создали словарь, который содержал различные свойства для всех сред (DEV, QA, PROD), он должен был применяться к общему шаблону, который содержал список конфигурацииВ файлах для всех сред программа Java заменила заполнители в шаблоне значениями в словаре для создания файлов конфигурации для всех сред, поэтому все конфигурации теперь управляются на уровне кода из созданного нами словаря.Java-программа выполнялась внутри сборки maven, которая также копировала любые другие ресурсы, которые могут нам понадобиться в создаваемых файлах конфигурации (например, сертификаты), все это было упаковано и развернуто на сервере через Jenkins, где в последнемЧасть сценариев bash поместит файлы конфигурации в нужную папку, тем самым автоматизируя все.