Управляйте несколькими файлами конфигурации приложения во время разработки
Я создаю приложение, которое используется несколькими различными клиентами. У каждого клиента есть изрядное количество пользовательской бизнес-логики, которую я умно осуществил рефакторинг в блок, который загружается во времени выполнения. Название того блока, наряду со многими другими настройками для конкретного заказчика, хранится в конфигурационном файле приложения.
Прямо сейчас вот то, что я должен сделать для отладки приложения для клиентского нечто:
- Перейдите к файловой системе в моем каталоге проекта и удалите
app.config - Копия
app.config.fooкому:app.config.foo - Copy. - Переименовать
app.config.foo - Copyкакapp.config. - Скажите Windows, что да, я хочу изменить расширение файла.
- Переключитесь назад на Visual Studio.
- Откройтесь
Settings.settingsобъект в моем проекте. - Нажмите "Yes" 13 или 14 раз, как VS просит меня, если я хочу использовать новые настройки, которые были изменены в
app.config. - Закрыть
Settings.settings.
Хорошо! Теперь я готов отладить!
Мне что rigamarole открытия кажется Settings.settings или должен быть, ненужный: Мне не нужны значения по умолчанию в Settings.cs быть повторно созданным, потому что я не использую их. Но это - единственный способ, которым я знаю о сделать VS, знающий о том, что app.config файл изменился, так, чтобы сборка скопировала его в выходной каталог.
Там получен, чтобы быть более легким способом сделать это.Что это?
3 ответа
Несколько человек предложили использовать несколько конфигураций VS, что, я думаю, сработало бы, за исключением того, что мне потребовалось бы перестраивать решение каждый раз, когда я переключаюсь между конфигурациями.
Что я сделал. вместо этого казалось немного глупым, пока я этим занимался, но я использую его уже почти год, и он работает очень плавно. В моем проекте непосредственно я создаю отдельный файл app.config.XXX для каждого клиента. Фактический файл app.config используется исключительно для создания Settings.cs - он имеет все правильные имена настроек и их значения по умолчанию. Он никогда не копируется в каталоги сборки.
Затем я написал небольшую программу, которая позволяет мне выбирать клиента, которая просто просматривает каталоги для каждого проекта и, если я выбрал клиента XXX, копирует app.config.XXX в bin \ debug \ myprogram.exe.config и bin \ release \ myprogram.exe.config . Пока эта программа знает, где находится корень решения (я должен быть немного осторожен при каждом ответвлении кода), она работает как шарм.
Можно отослать это сообщение для некоторых хороших методов: Управление Несколькими Средами Конфигурационного файла с Событиями Перед сборкой
Вы можете определить несколько конфигураций решения Visual Studio, по одной для каждого клиента, и настроить целевые объекты MSBuild для своего проекта приложения Windows.
Я задокументировал шаги того, как я справился с этим Вот. Несколько файлов app.config для развертывания в разных средах