Как условно развернуть app.config на основе конфигурации сборки? - PullRequest
18 голосов
/ 08 декабря 2008

У меня есть три пользовательские конфигурации сборки {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 и т. Д.) Для каждой среды. Однако значения конфигурации приложения не меняются между отладкой / выпуском.

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

Ответы [ 5 ]

9 голосов
/ 09 декабря 2008

Мы исправили это, используя элемент Choose в файле csproj. У нас настроено несколько разных конфигураций, поэтому все, что мы делаем, это добавляем этот блок в ваш proj-файл, и вы можете использовать конфигурацию VS, чтобы помочь вам. Я хочу, чтобы второй совет Роба переместил пройденный 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>

6 голосов
/ 08 декабря 2008

Что-то вроде

<PropertyGroup Condition="'$(Configuration)'=='Dev_Debug' OR '$(Configuration)'=='Dev_Release'" >
    <CfgFileName>Dev</CfgFileName>
</PropertyGroup>
<!-- similar for Qs & Prd -->
<Target ...>...$(CfgFileName).config...
1 голос
/ 03 декабря 2009

Как насчет использования сервера сборки?
Прошло много времени с тех пор, как я работал в .NET, но разве вы не можете использовать сервер, похожий на Hudson, для управления конфигурациями сборки? Не проще ли?
А как насчет NAnt? Разве это не соответствует вашим потребностям?

1 голос
/ 08 декабря 2008

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

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

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

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

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

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

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

0 голосов
/ 08 декабря 2008

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...