Исключить app.config из системы контроля версий?

Question

Как лучше всего разрешить членам команды настраивать свой собственный app.config, но при этом сохранять авторитетную версию в системе контроля версий? Лучше ли исключить все файлы * .config из системы контроля версий и использовать файл app.config.template в системе управления версиями?

Answer 1

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

К счастью, теперь вы можете экспортировать настройки в разделы appSettings, connectionStrings и т. Д., Используя свойство file для appSettings и свойство configSource для других разделов.

К сожалению, документация для configSource скрыта в MSDN , поэтому я полагаю, что она не так широко известна. Предоставленная документация также довольно мягкая, но здесь есть намного лучшее объяснение:

Рекомендации по настройке ASP.NET ConnectionStrings и AppSettings в Web.Config

Перефразируя, вы можете делать такие вещи:

<appSettings file="webAppSettings.config">
  <add key="UseCache" value="True"/>
  <add key="MapsKey" value="1234567890-AA"/>
  <add key="SMTPServer" value="smtp.peterkellner.net"/>
</appSettings>

<connectionStrings configSource="WebConnectionString.config">
</connectionStrings>

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

Answer 2

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

Вы хотите, чтобы ваша scm игнорировала сам файл конфигурации, чтобы ваши разработчики не могли случайно зафиксировать его в хранилище.

Answer 3

Нет ни одного "лучшего пути". Это зависит от команды и окружающей среды.

Обсудите это с членами вашей команды и решите, что подойдет для вашей ситуации. Предоставление вам «это лучший способ» может не сработать в ваших конкретных обстоятельствах.