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