Управления конфигурационными файлами в .net проектах

[lair]

Я еще понимаю, зачем это нужно для app.config. Но для web-config-то зачем, с учетом наличия вполне рабочих config transforms?

[AndrewOrsich]

Отличный вопрос!
Простой ответ — setty удобнее и имеет несколько дополнительных плюшек.

Более развёрнутый:
1. Setty не мешает использовать web.config transforms.
2. Setty позволяет использовать одни и теже настройки для разных конфигов в солюшене (или вообще для разных проектов на одном компьютере, по принципу иерархических конфигов).
3. Так есть возможность добавлять различную логику в конфиге. См. пример об отправке почты из введения.
4. Если разработчик хочет поменять какие то настройки для его локальной машины ему гораздо проще создать личный конфиг и делать там всё что ему захочется. Не уверен возможно ли это сделать с web.config transforms, так как там вы всегда завязаны на на определённую build configuration(debug, release, etc.). Создавать новую build configuration то же не вариант, так как вам всё время придётся переключаться на её после того, как вы забираете последнюю версии с репозитория, ибо все работают в debug…
5. И если у вас на проекте 10 различных конфигураций (Prod, Stage, Stage v2.0., Dev, etc..)…

[lair]

Setty не мешает использовать web.config transforms.

И как они сочитается.

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

Это вот этот:

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

Так это типичная ситуация «конфиг на среду», никакой логики.

И если у вас на проекте 10 различных конфигураций (Prod, Stage, Stage v2.0., Dev, etc..)…

То что? У нас это прекрасно разруливается через config transforms.

И ладно бы это, еще ведь есть трансформы в веб-деплое.

[AndrewOrsich]

Setty не мешает использовать web.config transforms.

И как они сочитается.

Setty генерирует конфиг с помощью шаблона и настроек типа ключ/значение перед каждым билдом. В то время как трансформация происходит на этапе паблишинга или веб деплоймента

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

Это вот этот:

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

Так это типичная ситуация «конфиг на среду», никакой логики.

Да, согласен, не доработал пример. Исправлюсь.

К примеру, на локальных машинах разработчиков отправленная почта должна сохранятся на диске, в то время как на тестовом сервере почта должна отправлятся с использованием сервиса отправки почты. А разработчик «Айвано» занимающийся интеграцией с сервисом отправки почты, используя тестовый логин/пароль заказчика, с ограничением в 20 писем в день, проверяет отправляется ли всё-таки почта и смотрит, что бы в письмах не было ошибок. Разработчик «Кристо», написавший модуль для сжатия запросов, проверяет корректно ли работает ajax и проводит нагрузочное тестирование.
Вообщем таких примеров, когда разработчику нужна полная свобода при настройке приложения, можно привести много. При этом всегда помнить о том, что эти изменения нужно не закомитить они не хотят, а если и хотят, то обязательно забудут.

И если у вас на проекте 10 различных конфигураций (Prod, Stage, Stage v2.0., Dev, etc..)…

То что? У нас это прекрасно разруливается через config transforms.

И ладно бы это, еще ведь есть трансформы в веб-деплое.

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

Этим я не хочу сказать, что я ярый противник «config transforms». Вполне себе нормальная вещь, имеющая право на существование и, возможно, подходящая для многих проектов. В то же время не лишённая «недостатков»… Setty пытается решить некоторые из них.

[crYpt]

Под web.config transforms вы подразумеваете xsl трансформации или XML-Document-Transform?

[AndrewOrsich]

Вроде это называется «Web.config Transformation», но я полагаю правильный ответ на ваш вопрос XML-Document-Transform(судя по схеме для трансформации).

[crYpt]

Замена декларативной трансформаций на общий шаблон + плоский ключ-значение файл настроек это, по-моему, не очень удобно.
Чтобы в дочернем конфиге изменить параметр, не обрабатываемый в шаблоне — придется модифицировать шаблон. В итоге он может превратиться в монстра с кучей if — else для всех возможных вариантов конфигурации.

[AndrewOrsich]

Чтобы в дочернем конфиге изменить параметр, не обрабатываемый в шаблоне — придется модифицировать шаблон. В итоге он может превратиться в монстра с кучей if — else для всех возможных вариантов конфигурации.

Да, согласен, но таких примеров как правило мало, за два года использования не один setty шаблон не превратился в монстра. Да и к тому же для таких вещей, где не просто меняется какое-то значение, а добавляется, удаляется какая то секция, меняется структура дочернего конфига, причём координально для разных конфигураций — «web config transformation» отлично подходит. А один-два if, только украшают шаблон конфига.

[lair]

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

Формально это тоже не логика, а разные среды.

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

Вообще-то, трансформы так и работают — вы легко можете переопределить только нужное.

[AndrewOrsich]

Формально это тоже не логика, а разные среды.

Возможно.

Вообще-то, трансформы так и работают — вы легко можете переопределить только нужное.

Ну скажем, для того что бы поменять строку подключения к БД для продакшена вам нужна трансформация вроде этой:

<configuration xmlns:xdt="...">
  <connectionStrings>
    <add name="MyConnectionString" connectionString="new_connection_string"
       xdt:Transform="Replace" 
       xdt:Locator="Condition(@name='MyConnectionString')" />
  </connectionStrings>
</configuration>

В Setty вам достаточно поменять значение в своём конфиге. И согласитесть, что бы поменять строку подключения к БД на свою локальную — вы не будете писать трансформацию и создавать новую среду, вы просто поменяте(а потом возможно забудете вернуть перед комитом (я по себе сужу)). Setty и трансформации отлично сочитаются.

[lair]

Ну скажем, для того что бы поменять строку подключения к БД для продакшена вам нужна трансформация вроде этой

Копирования здесь нет, это как раз типичное переопределение нужного.

Setty и трансформации отлично сочитаются.

Об этом я не спорю. Я просто намекаю, что надо понимать границы и осмысленность применимости всех инструментов.

[AndrewOrsich]

Копирования здесь нет, это как раз типичное переопределение нужного.

В данном случае нам нужно переопределить только значение строки подключения. Программисты педанты по своей натуре, и всегда ищут пути как сделать красивше чем есть.

Об этом я не спорю. Я просто намекаю, что надо понимать границы и осмысленность применимости всех инструментов.

Уж очень тонкие намёки, не понял так сразу. Абсолютно с Вами согласен. Просто было желание поделится подходом, который мы используем на многих проектах, и у которого есть свои плюсы и «области применения». Setty естественно не для всех.

[kefirr]

Web config transforms, кстати, аналогично работают для app.config, я это запиливал на прошлом проекте. Просто надо ручками proj файл отредактировать.

[altern]

Самый простой способ избежать конфликтов в конфигурационных файлах — это хранить шаблон конфигурационного файла в системе контроля версий. Например, если приложение использует файл db.properties, то в системе контроля версий должен храниться файл db.properties.tmpl. При первой загрузке изменений из системы контроля версий (update, pull, etc) каждый разработчик переименовывает .tmpl файл избавляясь от расширения (так как приложение использует db.properties, без наличия этого файла ничего работать не будет) и заодно подставляя нужные ему значения конфигурации. При последующих обновлениях шаблона конфигурационного файла каждый разработчик будет видеть что добавились новые параметры и что нужно добавить соответсвующие декларации в свой конкретный конфигурационный файл при этом подставив нужные значения.

[AndrewOrsich]

Да, согласен.

Setty работает подобным образом. Но при добавлении каких то общих настроек в систему вам не нужно будет их копировать в свой личный конфиг, так как вы просто добавляете настройки в конфиг верхнего уровня и они автоматически становятся доступны для всех. А если нужно поменять эту настройку — Вы просто копируете её в свой конфиг и меняете. Так же если использовать setty, Вы продолжаете работать с *.config файлами и читать настройки привычным образом. В дополнение, при развёртывании вам нужно будет изменить db.properties файл, и все эти изменения останутся на сервере (что не всегда возможно, если использовать appharbor к примеру). Setty позволяет хранить настройки для всех конфигураций в системе контроля версий.

Вообщем смысл тот же, но Setty добавляет немного автоматизации и опять же пару плюшек…