Я полагаю, что ваш вопрос показывает, что вы переросли app.config
- пришло время перейти к лучшему решению и приступить к решению некоторых смежных вопросов.
Во-первых, вы НИКОГДА не должны автоматически развертывать файл конфигурации в рабочей среде, и вы должны ожидать, что персонал службы поддержки решительно отклонит любую попытку сделать это. Конечно, если вы работники службы поддержки, вам следует отказаться от него самостоятельно. Вместо этого ваш выпуск должен включать некоторые инструкции по обновлению файла конфигурации вручную, с примером для иллюстрации. Конфигурация производства слишком важна для незначительных мер, если вы просто не очень цените свою производственную систему.
Аналогично для тестовых и других сред, но в меньшей степени, так что вам действительно нужно, чтобы ваш app.config
был заполнен только для вашей собственной разработки.
Один из вариантов - объединить несколько конфигураций в один app.config
, что целесообразно для небольших, относительно неважных приложений или на ранних стадиях разработки / выпуска. Например, создайте параметр конфигурации, который называется что-то вроде target-env
, который содержит значение, которое вы используете в своем коде для выбора других параметров конфигурации, например, добавив значение к клавишам других параметров конфигурации.
Я предпочитаю пройти мимо app.config
или использовать его минимально. В этом случае я предпочитаю поместить достаточно данных конфигурации в файл, чтобы позволить моему приложению / системе подключиться к своей базе данных, а затем я поместил оставшиеся детали конфигурации в специальную таблицу базы данных для этой цели. Это имеет много преимуществ, таких как информирование базы данных о среде, которую она представляет (dev, test, production и т. Д.) И совместное использование конфигурации и других данных. В этом случае пакет развертывания можно должным образом сохранять в отношении конфигураций и различий среды - код просто получает доступ к своим данным конфигурации и действует соответствующим образом, поэтому один и тот же пакет развертывания подходит для любой среды.
Однако ключевым фактором успеха этого подхода является то, что код вашего приложения должен «знать», что он ожидает от конфигурации, и он должен «знать», чтобы отклонить неправильную / неполную конфигурацию. Здесь вы должны провести время, не пытаясь обойти пределы app.config
.
Это обычно означает создание собственного класса для доступа к данным конфигурации, а затем использование этого класса во всем приложении. Это также приводит ко многим другим преимуществам, таким как строго типизированные данные конфигурации: вместо String
возвращается DateTime
, или Url
, или Integer
, или Currency
, или как угодно лучше. подходит для данных конфигурации и приложения.