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

Question

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

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

Так что, если у меня есть один web.config и четыре тестовых проекта с файлами app.config, у меня должно быть 5 копий этих строк подключения.

Есть ДОЛЖЕН быть лучший способ, чем копировать / вставлять эти строки соединения между всеми этими файлами конфигурации.

У кого-нибудь есть рекомендации? Я рассмотрел преобразования, которые происходят с web.config и проектами веб-развертывания, но это не помогает во время разработки / тестирования.

Есть идеи?

Спасибо, Mike

Answer 1

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

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

Answer 2

Вот что я делаю:

<add key="PRODSSERVERNAME.DataBaseEnvironment"    value="PROD" />
<add key="STAGESERVERNAME.DataBaseEnvironment"    value="STAGE" />
<add key="DEVSERVERNAME.DataBaseEnvironment"    value="DEV" />

Для имен используйте имя ПК. Вы можете найти его, запустив hostname из командной строки.

Затем вы делаете это:

<add key="DB,DEV"           value="Data Source=[DEV STRING] />
<add key="DB,STAGE"         value="Data Source=[STAGE STRING] />
<add key="DB,PROD"          value="Data Source=[PROD STRING] />

Затем вы пишете функцию:

protected string GetConnectionString() {
    string machineName  = String.Concat(System.Environment.MachineName, .DatabaseEnvironment");
    string environment  = ConfigurationManager.AppSettings[machineName];
    string Key       = String.Concat("DB", ",", environment);
    string value       = ConfigurationManager.AppSettings[ssoKey];

    return value;
}

Answer 3

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

т.е.

prod_Web.config

beta_App.config

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

Answer 4

Обычно мы используем несколько файлов web.config и позволяем процессу сборки и развертывания определить, какой файл относится к какой среде. Таким образом, наше решение будет иметь файл web.config для ПК локального разработчика, а затем web.dev.config, web.test.config и web.prod.config. Это приводит к дублированию файлов конфигурации, но позволяет четко разграничить среды. Поскольку наши выпуски выпускаются достаточно редко, я вручную проверю, все ли настройки, добавленные в файл web.test.config, также оказались в файле web.prod.config перед выпуском.