Разграничение web.config между разработкой, подготовкой и производственной средой

У кого-нибудь есть хорошие советы по обработке различий в настройках web.config между средами? Я'мы думали создатьконфигурации» В нашей системе управления версиями, но за пределами веб-иерархии, и в процессе развертывания скопируйте соответствующие файлы конфигурации (web.dev.config, web.staging.config, web.production.config) в веб-папку после развертывания. Я'Мы также видели сообщения о том, как программно изменять параметры конфигурации (конечные точки WCF, строки подключения и т. д.) при запуске приложения.

Что здесь считается наилучшей практикой и какой опыт у каждого был с тем или иным подходом?

Обновление сентябрь 2010

Это'Стоит отметить, что Visual Studio 2010 добавляет эту возможность черезпреобразования web.config, Когда вы используете менеджер конфигурации сборки (Build | Configuration Manager ...) для создания различных конфигураций для вашего проекта (скажем, Debug, Dev, Staging и Release), VS добавляет файлы web. *. Config в решение. Файл web.config по умолчанию содержит базовые настройки, которые выбуду использовать для отладки. web.release.config, web.staging.config и т. д. содержат XSLT-преобразования, которые будут применяться всякий раз, когда вы публикуете свой проект на основе активной конфигурации сборки.

Ответы на вопрос(9)

Ваш ответ на вопрос