Конфигурация .NET (app.config / web.config / settings.settings)

Question

У меня есть приложение .NET, в котором есть разные файлы конфигурации для сборок Debug и Release. Например. файл debug app.config указывает на разработку SQL Server , для которой включена отладка, а цель выпуска указывает на работающий SQL Server. Существуют также другие настройки, некоторые из которых отличаются в отладке / выпуске.

В настоящее время я использую два отдельных файла конфигурации (debug.app.config и release.app.config). У меня есть событие сборки проекта, в котором говорится, что если это сборка выпуска, скопируйте файл release.app.config в app.config, иначе скопируйте debug.app.config в app.config.

Проблема в том, что приложение, похоже, получает свои настройки из файла settings.settings, поэтому мне нужно открыть settings.settings в Visual Studio, которая затем предлагает мне изменить настройки, поэтому я принимаю изменения, сохраняю настройки. настройки и придется восстановить, чтобы он использовал правильные настройки.

Есть ли лучший / рекомендуемый / предпочтительный метод для достижения аналогичного эффекта? Или в равной степени я подошел к этому совершенно неправильно и есть ли лучший подход?

Answer 1

Любая конфигурация, которая может отличаться в разных средах, должна храниться на уровне машины , а не на уровне приложения . (Подробнее об уровнях конфигурации.)

Это элементы конфигурации, которые я обычно храню на уровне машины:

• Настройки приложения
• Строки подключения
• розничная = правда
• Настройки Smtp
• Мониторинг здоровья
• Хостинг
• Машинный ключ

Когда каждая среда (разработчик, интеграция, тестирование, этап, live) имеет свои уникальные настройки в каталоге c: \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ CONFIG , тогда вы может продвигать ваш код приложения между средами без каких-либо модификаций после сборки.

И, очевидно, содержимое каталога CONFIG на уровне компьютера получает управление версиями в другом хранилище или структуре папок, отличной от вашего приложения. Вы можете сделать ваши файлы .config более удобными для управления исходным кодом с помощью интеллектуального использования configSource .

Я занимаюсь этим уже 7 лет на более чем 200 приложениях ASP.NET в более чем 25 различных компаниях. (Не пытаясь похвастаться, просто хочу сообщить, что я никогда не видел ситуации, когда этот подход не работает.)

Answer 2

Это может помочь некоторым людям, имеющим дело с Settings.settings и App.config: обратите внимание на атрибут GenerateDefaultValueInCode на панели свойств при редактировании любого значения в сетке Settings.settings в Visual Studio (в моем случае Visual Studio 2008 ).

Если вы установите для GenerateDefaultValueInCode значение True (True здесь по умолчанию!), Значение по умолчанию компилируется в EXE (или DLL), вы можете найти его в файле при его открытии в текстовом редакторе.

Я работал над консольным приложением и, если у меня были значения по умолчанию в EXE, приложение всегда игнорировало место файла конфигурации в том же каталоге! Весьма кошмар и никакой информации об этом во всем Интернете.

Answer 3

Здесь есть связанный вопрос:

Улучшение процесса сборки

Файлы конфигурации поставляются с возможностью переопределения настроек:

<appSettings file="Local.config">

Вместо того, чтобы проверять два файла (или более), вы регистрируете только файл конфигурации по умолчанию, а затем на каждом целевом компьютере вы помещаете файл Local.config, содержащий только раздел appSettings, который имеет переопределения для этого конкретного компьютера .

Если вы используете разделы конфигурации, эквивалент:

configSource="Local.config"

Конечно, неплохо было бы сделать резервные копии всех файлов Local.config с других машин и где-то проверить их, но не как часть реальных решений. Каждый разработчик помещает «ignore» в файл Local.config, чтобы он не регистрировался, что перезаписывает файл всех остальных.

(На самом деле вам не нужно называть это «Local.config», это именно то, что я использую)

Answer 4

Из того, что я читаю, похоже, что вы используете Visual Studio для процесса сборки. Задумывались ли вы об использовании MSBuild и Nant вместо этого?

Синтаксис Нанта в xml немного странный, но как только вы его понимаете, то, что вы упомянули, становится довольно тривиальным.

<target name="build">
    <property name="config.type" value="Release" />

    <msbuild project="${filename}" target="Build" verbose="true" failonerror="true">
        <property name="Configuration" value="${config.type}" />
    </msbuild>

    <if test="${config.type == 'Debug'}">
        <copy file=${debug.app.config}" tofile="${app.config}" />
    </if>

    <if test="${config.type == 'Release'}">
        <copy file=${release.app.config}" tofile="${app.config}" />
    </if>

</target>

Answer 5

Мне кажется, что вы можете извлечь выгоду из Visual Studio 2005 Web Deployment Project s.

При этом вы можете указать ему обновлять / изменять разделы вашего файла web.config в зависимости от конфигурации сборки.

Взгляните на эту запись в блоге Скотта Гу для быстрого обзора / образца.

Answer 6

Мы использовали проекты веб-развертывания, но с тех пор перешли на NAnt. Вместо того, чтобы разветвлять и копировать различные файлы настроек, мы в настоящее время встраиваем значения конфигурации непосредственно в скрипт сборки и внедряем их в наши файлы конфигурации с помощью задач xmlpoke:

  <xmlpoke
    file="${stagingTarget}/web.config"
    xpath="/configuration/system.web/compilation/@debug"
    value="true"
  />

В любом случае ваши конфигурационные файлы могут иметь любые значения разработчика, которые вы хотите, и они будут нормально работать в вашей среде разработки, не нарушая ваших производственных систем. Мы обнаружили, что разработчики с меньшей вероятностью произвольно изменяют переменные сценария сборки при тестировании, поэтому случайные неправильные конфигурации встречаются реже, чем при использовании других методов, которые мы пробовали, хотя по-прежнему необходимо добавлять каждую переменную в начале процесса, Значение dev по умолчанию не выдвигается в prod.

Answer 7

Мой текущий работодатель решил эту проблему, сначала поместив уровень dev (отладка, stage, live и т. Д.) В файл machine.config. Затем они написали код, чтобы подобрать его и использовать правильный файл конфигурации. Это решило проблему с неверной строкой подключения после развертывания приложения.

Они только недавно написали центральный веб-сервис, который отправляет обратно правильную строку подключения из значения в значении machine.config.

Это лучшее решение? Наверное, нет, но у них это работает.

Answer 8

Одним из решений, которое мне помогло, было использование WebDeploymentProject. У меня было 2/3 разных файлов web.config на моем сайте, и при публикации, в зависимости от выбранного режима конфигурации (выпуск / подготовка / и т. Д.), Я бы скопировал Web.Release.config и переименовал его в web. config в событии AfterBuild и удалите те, которые мне не нужны (например, Web.Staging.config).

<Target Name="AfterBuild">
    <!--Web.config -->
    <Copy Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\Web.Release.config" DestinationFiles="$(OutputPath)\Web.config" />
    <Copy Condition=" '$(Configuration)|$(Platform)' == 'Staging|AnyCPU' " SourceFiles="$(SourceWebPhysicalPath)\Web.Staging.config" DestinationFiles="$(OutputPath)\Web.config" />
    <!--Delete extra files -->
    <Delete Files="$(OutputPath)\Web.Release.config" />
    <Delete Files="$(OutputPath)\Web.Staging.config" />
    <Delete Files="@(ProjFiles)" />
  </Target>

Answer 9

У нашего proj есть та же проблема, где мы должны были поддерживать конфиги для dev, qa, uat и prod. Вот что мы следовали (применимо, только если вы знакомы с MSBuild):

Используйте MSBuild с расширением задач сообщества MSBuild. Он включает в себя задачу «XmlMassUpdate», которая может «массово обновлять» записи в любом файле XML после того, как вы дадите ему правильный узел для запуска.

Для реализации:

1) У вас должен быть один конфигурационный файл, в котором будут ваши записи dev env; это файл конфигурации в вашем решении.

2) Вам необходим файл Substitutiontions.xml, который содержит только записи, РАЗЛИЧНЫЕ (в основном appSettings и ConnectionStrings) для каждой среды. Записи, которые не изменяются в разных средах, не нужно помещать в этот файл. Они могут находиться в файле решения web.config и не будут затронуты задачей

3) В файле сборки просто вызовите задачу массового обновления XML и укажите в качестве параметра правильную среду.

См. Пример ниже:

    <!-- Actual Config File -->
    <appSettings>
        <add key="ApplicationName" value="NameInDev"/>
        <add key="ThisDoesNotChange" value="Do not put in substitution file" />
    </appSettings>

    <!-- Substitutions.xml -->
    <configuration xmlns:xmu="urn:msbuildcommunitytasks-xmlmassupdate">
      <substitutions>
        <QA>
           <appSettings>
            <add xmu:key="key" key="ApplicationName" value="NameInQA"/>
           </appSettings>            
        </QA>
        <Prod>
          <appSettings>
            <add xmu:key="key" key="ApplicationName" value="NameInProd"/>
          </appSettings>            
        </Prod>
     </substitutions>
    </configuration>


<!-- Build.xml file-->

    <Target Name="UpdateConfigSections">
            <XmlMassUpdate ContentFile="Path\of\copy\of\latest web.config" SubstitutionsFile="path\of\substitutionFile" ContentRoot="/configuration" SubstitutionsRoot="/configuration/substitutions/$(Environment)" />
        </Target>

заменить «$ Environment» на «QA» или «Prod» в зависимости от того, что env. Вы строите для. Обратите внимание, что вы должны работать с копией файла конфигурации, а не с самим файлом конфигурации, чтобы избежать возможных ошибок, которые невозможно исправить.

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

Для лучшего обзора прочитайте это:

http://blogs.microsoft.co.il/blogs/dorony/archive/2008/01/18/easy-configuration-deployment-with-msbuild-and-the-xmlmassupdate-task.aspx

Answer 10

Вы найдете другое решение здесь: Лучший способ переключения конфигурации между средами разработки / UAT / Prod в ASP.NET?, который использует XSLT для преобразования web.config.

Есть также несколько хороших примеров использования NAnt.