Автоматическое изменение файла web.config под контролем исходного кода во время сборки CI

Question

Я работаю с парой друзей на веб-сайте ASP.NET MVC. Проект поддерживается в SVN, и я настроил CC.Net для получения последней версии, а также для автоматической сборки и развертывания на подготовительном сервере. Конфигурация сборки по умолчанию установлена ​​на Отладка, а автоматическая сборка настроена на сборку Retail. Все работает отлично, за исключением <compilation debug=""> в web.config, который в настоящее время всегда имеет значение true. Я хотел бы иметь возможность указать true или false для <compilation debug=""> на основе варианта сборки.

Я думал о двух разных решениях этой проблемы.

У меня может быть шаг до / после сборки, который изменяет значение. Однако файл web.config находится под контролем исходного кода, поэтому изменение его в автоматической сборке оставит его проверенным на компьютере сборки. У меня также может быть дополнительный шаг, который также вернет его.

Я мог бы также вместо того, чтобы иметь web.config под управлением исходного кода, иметь файл web.config.base, который используется в качестве источника во время сборки для создания файла web.config. Проблема этого подхода заключается в том, что большинство инструментов напрямую изменяют файл web.config, и мы должны вручную объединить такие изменения в базовый файл. И поскольку нет никаких признаков того, что какой-либо инструмент изменил web.config, мы должны искать изменения при любой регистрации. Это не только становится утомительным шагом вручную, но и подвержено ошибкам.

Оба эти подхода будут работать, но имеют некоторые недостатки. Я надеялся, что есть более элегантный способ сделать это. Таким образом, вопрос - как вы, ребята, имеете дело с изменением web.config, который находится под контролем исходного кода во время сборки CI?

Answer 1

Вы можете взглянуть на надстройку Web Deployment Projects VS. Скотт Гатри делает большую работу, объясняя это в этой записи .

Answer 2

у нас есть

• web.config для разработки
• web.config.cert, который развертывается Hudson в нашей сертифицированной среде
• web.config.prod, который используется для производства

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

Как я уже сказал, у нас Hudson развертывается в нашей сертифицированной среде при каждой сборке, поэтому он просто копирует каталог, удаляет web.config и переименовывает web.config.cert в web.config

Возможно, вы захотите проверить Хадсон, я не думаю, что когда-либо слышал о том, чтобы кто-нибудь выбрал CC.net вместо Хадсона, если бы у него была возможность выбрать:)

Answer 3

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

AFAIK SVN все равно имеет файлы для чтения / записи.

Answer 4

Почему бы не изменить web.config как часть шага сборки, используя утилиту командной строки, которая может редактировать XML?

например. Получите утилиту командной строки, которая работает как:

xml_mod.exe web.config [xpath-of-value-to-change] [new-value]

Тогда для каждой отладки / выпуска (в розницу) значение будет разным.