web.config - автоматически генерировать релизную версию

Visual Studio 2010 поддерживает нечто подобное. Проверьте это здесь.

Как вы развертываете свои сборки. В моей среде это тоже было проблемой, но теперь мы используем CruiseControl.net и скрипты наших сборок в nant. В нашем скрипте мы определяем среду и имеем разные версии параметров конфигурации для каждой среды. См.: http://www.mattwrock.com/post/2009/10/22/The-Perfect-Build-Part-3-Continuous-Integration-with-CruiseControlnet-and-NANT-for-Visual.-Studio-Projects.aspx для моего сообщения в блоге на тему использования Cruisecontrol.net для управления сборкой. Перейдите в конец, чтобы получить краткое описание того, как мы обрабатываем версии конфигурации.

В моем последнем проекте я написал сценарий PowerShell, который загружал файл web.config, изменял необходимые элементы XML и снова сохранял файл. Примерно так:

param($mode, $src)
$ErrorActionPreference = "stop"
$config = [xml](Get-Content $src)

if ($mode -eq "Production")
{
    $config.SelectSingleNode("/configuration/system.web/compilation").SetAttribute("debug", "false")
    $config.SelectSingleNode("/configuration/system.web/customErrors").SetAttribute("mode", "off")
    $config.SelectSingleNode("/configuration/system.net/mailSettings/smtp/network").SetAttribute("host", "live.mail.server")
    $config.SelectSingleNode("/configuration/connectionStrings/add[@name='myConnectionString']").SetAttribute("connectionString", "Server=SQL; Database=Live")
}
elseif ($mode -eq "Testing")
{
    # etc.
}

$config.Save($src)

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

XSLT можно использовать для создания параметризованных XML-файлов. Web.config, являющийся файлом xml, этот подход работает.

У вас может быть один файл .xslt (с выражениями xpath).

Затем могут быть разные файлы xml, такие как 1. debug.config.xml 2. staging.config.xml 3. release.config.xml

Затем в событии после сборки или с помощью некоторых задач msbuild xslt можно объединить с соответствующими файлами xml, чтобы иметь другой файл web.config.

Образец файла debug.config.xml можно

<Application.config>
   <DatabaseServer></DatabaseServerName>
   <ServiceIP></ServiceIP>
</Application.config>

.xslt может иметь xpaths, ссылающиеся на xml, указанный выше.

Можете взглянуть на преобразование XSLT. Этот код можно использовать в некоторых задачах MSBuild. или задачи nant и разные web.config могут быть созданы в зависимости от входных файлов конфигурации xml.

Таким образом, вам просто нужно управлять файлами xml.

Есть только одна дополнительная нагрузка, связанная с необходимостью управления файлом xslt, который похож на файл web.config. то есть всякий раз, когда в web.config добавляется какой-либо тег, xslt также необходимо изменить.

Я не думаю, что вы можете на 100% избежать этого.

Последние годы работы всегда и везде показывают: где человек работал, там и неудачи.

Итак, вот 3 идеи из моей прошлой компании, может быть, не самые лучшие, но лучше, чем ничего:

1. Напишите пакетный файл или приложение C#.Net, которое изменит ваш файл web.config двойным щелчком.
2. Напишите список «ToDo on Release»
3. Займитесь парной реализацией (== парное программирование во время реализации :))