Несколько веб-настроек в одном

Question

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

Есть ли способ объединить их в один файл web.config?Так что я не перезаписываю продукцию разработчиками (или наоборот) при публикации сайта.

Answer 1

В VS 2010 вы можете сделать это с помощью преобразований web.config и создания конфигураций.Скотт Гатри написал об этом:

http://weblogs.asp.net/scottgu/archive/2010/07/29/vs-2010-web-deployment.aspx

Я думаю, что это в основном работает, если вы просто создаете дополнительные файлы конфигурации (такие как Web.Debug.config), и VS автоматически "связывает" ихна ваш основной web.config в IDE, но я не могу проверить это на компьютере, которым я сейчас пользуюсь, поскольку у него нет VS 2010.

Вы также можете сделать это довольно легко с событиями сборкив старых версиях VS, но это не так приятно.Скотт на самом деле тоже писал об этом:

http://weblogs.asp.net/scottgu/archive/2007/09/21/tip-trick-automating-dev-qa-staging-and-production-web-config-settings-with-vs-2005.aspx

(взято из поста Скотта в блоге) Вот высокоуровневые шаги, которые вы предпринимаете для этого.Они работают как с VS 2005, так и с VS 2008.

1. Использование проектов веб-приложений ASP.NET (в которых есть файлы проектов на основе MSBuild)
2. Откройте диспетчер конфигурации VS и создайте новый "Dev""," QA "," Staging "собирают конфигурации для вашего проекта и решения
3. Добавьте новые файлы" web.config.dev "," web.config.qa "и" web.config.staging "вваш проект и настройте его так, чтобы он содержал параметры конфигурации, специфичные для режима приложения
4. Добавьте в файл проекта новую команду «событие перед сборкой», которая может автоматически копировать файл web.config в ваш проект в соответствующем режимеконкретная версия каждый раз, когда вы строите проект (например: если ваше решение было в конфигурации «Dev», оно скопировало бы настройки web.config.dev в основной файл web.config).

Answer 2

Только одна возможность, но вы можете объединить их, дав соответствующие имена значениям на основе контекста, и получить доступ к каждому элементу условно, используя константы компиляции в коде.Например, в вашем файле web.config вы можете иметь ...

<connectionStrings>
    <add name="DevelopmentConnection" connectionString="DevelopmentConnectionString" />
    <add name="DeploymentConnection" connectionString="DeploymentConnectionString" />
</connectionStrings>

Тогда, скажем, в классе конфигурации, который вы можете иметь ...

public static class Configuration
{
    public string ConnectionString
    {
        get
        {
            #if DEBUG
                return ConfigurationManager.ConnectionStrings["DevelopmentConnection"].ConnectionString;
            #else
                return ConfigurationManager.ConnectionStrings["DeploymentConnection"].ConnectionString;
            #endif
        }
    }
}

Теперь,учитывая, что константа DEBUG определена, то при построении для каждой среды использование этого свойства будет проходить через соответствующую настройку.

Answer 3

Вы можете создать проект веб-развертывания ( VS2008 , VS2010 ), который представляет собой файл XML MSBuild, который позволяет заменять / вставлять / заменять узлы XML в файле конфигурации при сборке.для определенного профиля.Вероятно, вы потратите полдня на день, чтобы настроить его правильно, но время того стоит, поскольку это может сэкономить вам массу головной боли при развертывании (а также позволяет приблизиться на один шаг к развертыванию в один клик).

Примечание: для проектов веб-развертывания VS2008 вы, вероятно, захотите использовать Задачи сообщества MSBuild .Я не знаю, каково состояние для VS2010 с этими задачами - требуются ли они или нет.

Для наших задач веб-развертывания VS2008, использующих задачи сообщества MSBuild (которые мы используем под VS2010), это выглядитнемного похоже ...

<!-- ... -->
<Target Name="AfterBuild">
    <XmlMassUpdate Condition="'$(Configuration)|$(Platform)' == 'Release - Dev|AnyCPU'" ContentFile="$(OutputPath)\web.config" SubstitutionsFile="$(OutputPath)\web.Substitutions.config" ContentRoot="/" SubstitutionsRoot="/configuration/substitutions/dev" />
</Target>
<!-- ... -->

В каталоге нашего веб-приложения есть файл web.Substitutions.config, который немного похож на ...

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:xmu="urn:msbuildcommunitytasks-xmlmassupdate">
  <substitutions>

    <!-- dev settings-->
    <dev>
      <configuration>
        <appSettings file="">
          <add xmu:key="key" key="some_setting" value="a_value_is_here"/>
                </appSettings>
      </configuration>
    </dev>
    <prod> <!-- you get the idea --></prod>
   </substitutions>
</configuration>

Стоит упомянуть, что мы используем Team City для запуска наших проектов веб-развертывания без дополнительной настройки, и это работает без проблем. Hudson аналогично (и немного проще в настройке).