Управление несколькими файлами конфигурации приложения во время разработки

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

Прямо сейчас, вот что мне нужно сделать, чтобы отладить приложение для клиента foo:

  1. Перейдите в файловую систему в каталоге моего проекта и удалите app.config
  2. Скопируйте app.config.foo в app.config.foo - Copy.
  3. Переименуйте app.config.foo - Copy в app.config.
  4. Скажите Windows, что да, я хочу изменить расширение файла.
  5. Вернитесь в Visual Studio.
  6. Откройте элемент Settings.settings в моем проекте.
  7. Нажмите «Да» 13 или 14 раз, когда VS спросит меня, хочу ли я использовать новые настройки, которые были изменены в app.config.
  8. Закрыть Settings.settings.

Хорошо! Теперь я готов к отладке!

Мне кажется, что канитель открытия Settings.settings не нужна или должна быть ненужной: мне не нужно перегенерировать значения по умолчанию в Settings.cs, потому что я их не использую. Но это единственный известный мне способ сообщить VS о факте изменения файла app.config, чтобы сборка скопировала его в выходной каталог.

Должен быть более простой способ сделать это. Что это?


visual-studio .net c# app-config
person Robert Rossney    schedule 06.10.2008    source источник

Ответы (7)


arrow_upward
7
arrow_downward

Вы также можете позволить Visual Studio автоматизировать подход Роберта:

  1. Определите конфигурацию сборки для каждого клиента
  2. В событии после сборки просто скопируйте app.config.xxx в папку bin. Где XXX — имя конфигурации сборки, доступной в VS. Что-то вроде: xcopy app.config.$(ConfigurationName) $(OutDir)/app.config

VS разместит отдельную сборку для ваших клиентов в отдельных папках вместе с соответствующим конфигурационным файлом. корзина/Клиент1/ корзина/Клиент2/

person magravelle    schedule 22.08.2010

arrow_upward
3
arrow_downward

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

person Gulzar Nazim    schedule 06.10.2008
comment
Это работает, хотя это долгая работа над функциональностью, которая действительно должна быть в IDE. - person Jeremy; 07.10.2008
comment
Это также требует, чтобы я создал две конфигурации (отладка и выпуск) для каждого клиента. Это пахнет неправильным ответом для меня. - person Robert Rossney; 07.10.2008
comment
Это работает как шарм. Каждое место (QA/DEV1/Production) имеет свой собственный файл конфигурации. НУЛЕВАЯ ПРОБЛЕМА. Это просто работает. ты гений!! Я сделал это для app.config, который работает со службой WCF для каждого клиента в каждом местоположении. Работает как шарм. ты мой герой! - person Mickey Perlstein; 11.07.2012

arrow_upward
3
arrow_downward

Думая о беспорядке управления несколькими файлами конфигурации, я сделал этот инструмент: http://envride.codeplex.com/

Его цель именно в том, чтобы упростить управление несколькими configuration files автоматизированным способом. Я был бы очень рад, если бы вы взглянули на него.

person Rafael    schedule 15.04.2011

arrow_upward
2
arrow_downward

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

То, что я сделал вместо этого, казалось немного глупым, когда я это делал, но я использую его уже почти год, и он работает очень гладко. Непосредственно в своем проекте я создаю отдельный файл app.config.XXX для каждого клиента. Фактический файл app.config используется исключительно для создания Settings.cs — в нем есть все правильные имена настроек и их значения по умолчанию. Он никогда не копируется в каталоги сборки.

Затем я написал небольшую программу, которая позволяет мне выбирать клиента, и которая просто просматривает каталоги для каждого проекта и, если я выбрал клиента XXX, копирует app.config.XXX в bin\debug\myprogram.exe.config и bin\release\myprogram.exe.config. Пока эта программа знает, где находится корень решения (я должен быть немного осторожен, когда делаю ветки кода), она работает как шарм.

person Robert Rossney    schedule 03.09.2009

arrow_upward
2
arrow_downward

Этот поток слишком стар, чтобы представлять текущие инструменты в VS.

  1. Вы можете использовать надстройку, которая действует аналогично web.debug.config, но для app.config.

https://marketplace.visualstudio.com/items?itemName=GolanAvraham.ConfigurationTransform

  1. И для тех же преобразований app.config без аддона.

https://www.linkedin.com/pulse/multi-appconfig-visual-studio-2017-benjamin-davis/

person Menelaos Vergis    schedule 28.09.2018

arrow_upward
0
arrow_downward

Вы можете определить несколько конфигураций решения Visual Studio, по одной для каждого клиента, и настроить целевые объекты MSBuild для своего проекта приложения Windows.

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

person icelava    schedule 11.05.2009

arrow_upward
0
arrow_downward

После небольшого копания и работы я получил свой тестовый проект, работающий с несколькими конфигурациями,

  1. В диспетчере конфигураций создайте нужные вам конфигурации
  2. Скопируйте и вставьте свой app.config и добавьте имя конфигурации, в моем случае это AHI, FIV, MGC, поэтому мои файлы конфигурации выглядят так: App.AHI.config, App.MGC.config, App.FIV.Config. Вы можете назвать его как хотите, но соблюдайте те же правила.
  3. Добавьте событие после сборки. В моем случае это будет выглядеть так: xcopy $(ProjectDir)app.$(ConfigurationName).config $(TargetDir)$(TargetName).dll.config /y

вот мой пост, так что вы можете прочитать его с более подробной информацией

Выполнение тестового проекта с несколькими конфигурациями< /а>

person Sebastian Castaldi    schedule 18.02.2016