Как Вы обрабатываете несколько web.config файлов для нескольких сред?

То, как мы это делаем, это переопределение раздела AppSettings:

<appSettings file="../AppSettingsOverride.config">
    <add key="key" value="override" />    
    ...
</appSettings>

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

Редактировать ниже

Просто смотрел это: http://channel9.msdn.com/shows/10-4/10-4-Episode-10-Making-Web-Deployment-Easier/

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

В Visual Studio я создаю события сборки xcopy, и я храню все файлы конфигурации в папке конфигурации/. Вам только нужно одно событие для всех конфигураций при именовании файлов в честь конфигурации сборки: т.е. перезапись web.config с/config/web. $ (конфигурация) .config

Мой любимый способ заняться этим с эти configSource атрибут. По общему признанию я только использую это на одном элементе (<connectionStrings>), но он действительно обеспечивает простой способ загрузить и различные сегменты web.config (который я делаю в течение времени установки с помощью проекта WebSetup).

Я также использую сеть. DEV.config, сеть. TEST.config, сеть. PROD.config и т.д.

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

Однако я использовал NAnt, и я думаю, что он работает хорошо на это. Можно настроить сборки для различных сред. NAnt снимает некоторые показания, чтобы изучить, как использовать его, но это довольно гибко.

http://aspnet.4guysfromrolla.com/articles/120104-1.aspx

http://nant.sourceforge.net/

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

Это действительно зависит от того, какая разница между средами, которые заставляют вас использовать разные файлы web.config. Можете ли вы дать больше информации о том, почему каждая среда в настоящее время нуждается в отдельной среде?

У нас есть несколько обходных решений (не, все они сделаны с web.config, но той же идеей)

1. , Мы включаем несколько конфигурационных файлов в упакованное развертывание. Во время установки мы определяем среду, на которой мы устанавливаем.
2. Перемещают всю среду определенные настройки на Сервер базы данных для той среды. WebServer обеспечивает свою среду при запросе, чтобы имя сервера
3. Обеспечило несколько настроек (1 на среду), и использующий код запрашивают различные настройки.
4. Комбинация 2 и 3 (Переопределяют часть настроек на основе среды - например, название сервера приложений)

С помощью самых разных программ управления версиями (subversion, git и т. Д.) Вы можете игнорировать определенные файлы.

Таким образом, в subversion у меня было бы:

configure.template.php - этот файл является версионным и содержит шаблонные данные конфигурации, такие как пустой DSN's configure.php - этот файл игнорируется, поэтому изменения к нему не отслеживаются.

В Subversion способ сделать это:

svn pe svn: игнорировать. Откроется ваш редактор, затем вы наберете configure.php

Сохраните, выйдите, проверьте свои изменения, и все готово.