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

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

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

  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. Нажмите "Yes" 13 или 14 раз, как VS просит меня, если я хочу использовать новые настройки, которые были изменены в app.config.
  8. Закрыть Settings.settings.

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

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

Там получен, чтобы быть более легким способом сделать это.Что это?

10
задан Gary Barrett 1 November 2019 в 16:21
поделиться

3 ответа

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

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

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

2
ответ дан 3 December 2019 в 22:02
поделиться

Можно отослать это сообщение для некоторых хороших методов: Управление Несколькими Средами Конфигурационного файла с Событиями Перед сборкой

3
ответ дан 3 December 2019 в 22:02
поделиться

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

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

0
ответ дан 3 December 2019 в 22:02
поделиться
Другие вопросы по тегам:

Похожие вопросы: