Несколько разработчиков, использующих один web.config с разными настройками

Я создаю веб-приложение ASP.Net MVC. В команде есть несколько разработчиков, которые должны иметь разные настройки в файле web.config. Эти настройки предназначены для подключения к базе данных и локальной виртуальной машины Linux, к которой необходимо получить доступ. Есть и другие вещи, которые нам нужно будет добавить в будущем. Какова методология, которая может быть использована для каждого разработчика, чтобы иметь собственные пользовательские настройки в web.config, не опасаясь, что локальные настройки будут привязаны к исходному контролю?

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

Ответ 1

Большинство разделов в файле конфигурации config позволяют использовать атрибут configSource. Мы использовали этот атрибут для того, чтобы встраивать обычно деформированные разделы в отдельный файл. Каждый из этих часто изменяемых разделов будет иметь отдельные файлы *.dev.config и *.prd.config. Файлы *.dev.config были проигнорированы исходным элементом управления (git).

Производственное развертывание затем установит атрибут configSource для использования файлов *.prd.config. Опять же, это означает, что вам необходимо обновить два набора конфигурации. Я начал работать над решением, чтобы файлы *.prd.config и *.dev.config синхронизировались на уровне элемента, но просто не успели закончить его.

Ответ 2

Я не уверен, что это самое высокотехнологичное решение, но я просто вызываю свой web.config "web.config.sample" и добавляю web.config к svn: ignore. Это мешает разработчикам случайно проверить его.

Когда новый ключ добавляется в web.config, вам просто нужно запомнить его дубликат в файле web.config.sample.

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

Изменить: вы также можете настроить крюк предварительной фиксации, чтобы гарантировать, что никто не зарегистрировался в файле web.config в каталоге, который также содержит файл web.config.sample.

Изменить # 2: вы также можете настроить крюк после фиксации, который будет отправлять по электронной почте всех участников при обновлении web.config.sample, поэтому их приложения не начнут сбой при поиске отсутствующих ключей конфигурации. Я собираюсь сделать это в будущем.