Web.config Versioning

Question

В настоящее время я использую общую модель базы данных для нашей разработки. Я знаю, что лучше использовать локальные базы данных разработки для правильной работы с версией базы данных без того, чтобы один разработчик нарушал все остальные коды. Вот к чему я пытаюсь добраться. Однако у меня есть вопрос о файле web.config. Как я могу гарантировать, что каждый раз, когда у каждого разработчика есть своя локальная база данных разработки, ему не нужно вручную менять строку соединения с БД каждый раз, когда он получает обновление от источника управления? Каков наилучший способ сделать это?

Например, скажем, Джонни Dev совершает свое web.config, который содержит строку соединения, как это:

server=JohnnysBox;database=JohnnyAppDev1; 

Так что теперь Сьюзи Dev получает обновления, и она должна изменить свою строку подключения к этому:

server=SUE;database=development; 

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

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

Answer 1

Для конфигурации или файлы настроек, то, что вам нужно версии:

• а файлы шаблонов (server=@USER_NAME@;database=@DATABASE_NAME@;)
• один или несколько значений файлов
• один сценарий, способных заменить переменные справа значения

Answer 2

Использовать (локально) в качестве имени сервера sql и всегда ссылаться на локальный сервер. Это должно быть значение по умолчанию в файле web.config, который вы проверяете в исходном элементе управления.

Для установки «устанавливается», ваш установщик должен попросить пользователя, хочет ли он использовать удаленный сервер sql, и если да, обновите файлы web.config как часть процесса установки.

Answer 3

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

Answer 4

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

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

Answer 5

Это лишь частичное решение, но вы можете заставить всех разработчиков создать псевдоним для своего собственного SQL-сервера с помощью cliconfg.

Тогда web.config в системе управления версиями будет иметь, например:

server=LocalServerAlias;database=development 

Answer 6

Решение, которое мы придумали в моем офисе было то, что мы специально исключаем web.config от контроля версий, но только в WWW папка. Это позволяет разработчикам делать любые изменения, которые им необходимы локально.

В отдельной папке у нас есть «главная» копия web.config, которой является версия. По мере добавления новых разделов, ключей и т. Д. Разработчик обязан обновить основную копию.

Answer 7

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

http://msdn.microsoft.com/en-us/library/dd465326(VS.100).aspx

Затем исключить этот обычай Web.xxx.config из вашего хранилища.

Answer 8

Мы везем web.config. Итак, у меня есть один под названием Mattweb.config, и я могу поменять его по своему усмотрению, и он заменяет web.config ON MY LOCAL MACHINE ТОЛЬКО с содержимым Mattweb.config. Это не требует вмешательства со стороны меня.

Мы также используем «настоящий» web.config, чтобы я мог сравнивать с моей локальной версией, чтобы увидеть, были ли добавлены какие-либо дополнения или какие-либо другие изменения. Затем я просто обновляю файл Mattweb.config, и все снова хорошо.