Как условно развернуть app.config на основе конфигурации сборки?

У меня есть три пользовательских конфигурации сборки {Dev, Qs, Prd}. Итак, у меня есть три конфигурации приложений {Dev.config, Qs.config, Prd.config}. Я знаю, как отредактировать файл .csproj, чтобы вывести правильный, основанный на текущей конфигурации сборки.

<Target Name="AfterBuild">
   <Delete Files="$(TargetDir)$(TargetFileName).config" />
   <Copy SourceFiles="$(ProjectDir)$(Configuration).config" DestinationFiles="$(TargetDir)$(TargetFileName).config" />
</Target>

Моя проблема в том, что мне нужно иметь шесть конфигураций сборки {Dev, Qs, Prd} x {Debug, Release}. Мне нужно поддерживать настройки отладки и выпуска (оптимизации, pdb и т.д.) Для каждой среды. Однако значения конфигурации приложения не изменяются между debug/release.

Как сохранить конструкцию script как можно более общую и использовать только три конфигурации приложений? Я не хочу жестко кодировать слишком много условных строк.

Ответы

Ответ 1

Что-то вдоль линий

<PropertyGroup Condition="'$(Configuration)'=='Dev_Debug' OR '$(Configuration)'=='Dev_Release'" >
    <CfgFileName>Dev</CfgFileName>
</PropertyGroup>
<!-- similar for Qs & Prd -->
<Target ...>...$(CfgFileName).config...

Ответ 2

Мы исправили это с помощью элемента Choose в файле csproj. У нас есть несколько различных конфигураций, поэтому все, что мы делаем, это удалить этот блок в ваш файл proj, и вы можете использовать VS Configuration, чтобы помочь вам. Я хочу, чтобы второй совет Роба переместил переданный app.config. Я двигаюсь в этом направлении в течение некоторого времени.

  <Choose>
<When Condition=" '$(Configuration)' == 'Debug' ">
  <ItemGroup>
    <None Include="App.config" />
    <None Include="Release\App.config" />
  </ItemGroup>
</When>
<Otherwise>
  <ItemGroup>
    <None Include="Release\App.config">
      <Link>App.config</Link>
    </None>
  </ItemGroup>
</Otherwise>

Ответ 3

Вот хорошая Обсуждение в scott Hanselmans об автоматизации множественной конфигурации.

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

Ответ 4

Я предлагаю, чтобы ваш вопрос показал, что вы переросли app.config - пришло время перейти к лучшему решению и начать решать некоторые связанные с этим проблемы.

Во-первых, вы НИКОГДА не должны автоматически развертывать конфигурационный файл для производства, и вы должны ожидать, что персонал службы поддержки решительно отвергнет любую попытку сделать это. Конечно, если вы персонал службы поддержки, то вы должны отказаться от него самостоятельно. Вместо этого в вашем выпуске должны быть указаны некоторые инструкции для ручного обновления файла конфигурации с примером для иллюстрации. Конфигурация производства слишком важна для меньших мер, если вы просто не очень цените свою производственную систему.

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

Опция заключается в интеграции нескольких конфигураций в один app.config, что разумно для небольших, относительно неважных приложений или на ранних этапах разработки/выпуска. Например, создайте параметр конфигурации, называемый target-env, который содержит значение, которое вы используете в своем коде, чтобы выбрать другие параметры конфигурации, например, добавив значение к клавишам других параметров конфигурации.

Мое предпочтение состоит в том, чтобы полностью пройти мимо app.config или использовать его минимально. В этом случае я предпочитаю вставлять только достаточно данных конфигурации в файл, чтобы позволить моему приложению/системе подключаться к его базам данных, затем я поместил остальные данные конфигурации в специальную таблицу базы данных для этой цели. У этого есть много преимуществ, например, чтобы база данных "знала" о том, какая среда она представляет (dev, test, production и т.д.) И сохраняя конфигурацию и другие данные вместе. После этого пакет развертывания может быть оставлен немым в отношении конфигураций и различий в среде - код просто обращается к своим конфигурационным данным и действует соответственно, поэтому один и тот же пакет развертывания подходит для любой среды.

Однако ключевым фактором успеха этого подхода является то, что ваш код приложения должен "знать", что он ожидает для конфигурации, и он должен "знать", чтобы отклонить неправильную/неполную конфигурацию. Здесь вы должны тратить свое время, не пытаясь работать в пределах app.config.

Это обычно означает создание собственного класса для доступа к данным конфигурации, а затем использование этого класса в вашем приложении. Это также приводит ко многим другим преимуществам, таким как строго типизированные данные конфигурации: вместо String верните a DateTime или Url, или Integer, или Currency, или что угодно лучше подходит для данных конфигурации и приложения.

Ответ 5

Как использовать сервер сборки? Это было давно, так как я работал в .NET, но не могу ли вы использовать сервер Hudson (-like) для управления вашими конфигурациями сборки? Не проще?
А как насчет NAnt? Не соответствует ли это вашим потребностям?

Ответ 7

Последнее решение, которое я хотел бы использовать, - создать 6 конфигураций приложений, 1 на пользовательскую конфигурацию

{Dev_Debug.config, Dev_Release.config, Qs_Debug.config, ..., Prd_Release.config}.

Хотя с этой настройкой я мог бы поддерживать общую конструкцию script, не используя условные строки.