Общие файлы конфигурации в .NET

У меня есть решение, которое включает в себя как веб-приложение, так и приложение-службу Windows NT. Это, конечно, два разных проекта, но в рамках одного решения. Однако во многом они имеют одинаковую конфигурацию.

В настоящее время у меня одинаковые значения как в файле web.config, так и в файле app.config. Это начинает становиться беспорядочным, и я хотел бы иметь общие файлы конфигурации для обоих приложений в рамках решения.

  • Есть ли проблема для веб-приложения, если конфигурация не на корневом уровне веб-приложения? Есть ли здесь ограничения?
  • Потеряю ли я кеширование и автоматическую перезагрузку веб-приложения, если не буду использовать web.config
  • Распространять конфигурацию, как описано, - это вообще плохая идея?

.net configuration asp.net-mvc windows-services
person Riri    schedule 04.05.2009    source источник

Ответы (2)


arrow_upward
9
arrow_downward

Что ж, вы можете «экстернализовать» определенные части конфигурации в отдельные файлы .config и использовать их из обоих мест.

Например. вы можете экстернализовать настройки строки подключения следующим образом:

<connectionStrings configSource="connectionStrings.config" />

а затем создайте файл "connectionString.config" следующим образом:

<?xml version="1.0" encoding="utf-8"?>
<connectionStrings>
  <add name="ConfigurationDatabase" 
       connectionString="server=.;Integrated Security=true;database=test"/>
  <add name="TestDatabase" 
       connectionString="server=TEST;Integrated Security=true;database=test"/>
</connectionStrings>

По сути, любой ConfigurationSection имеет такую ​​настройку configSource, которая позволяет вам указать внешний файл для использования.

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

Марк

person marc_s    schedule 04.05.2009
comment
Атрибут configSource не позволяет вам помещать в него .. или ~ / и указывает, что он должен ссылаться на файл в том же каталоге или в подкаталоге, что и файл конфигурации. Учитывая это, как два проекта могут совместно использовать внешний файл, если ни один из них не может попасть на уровень каталогов выше, чем он сам? - person James in Indy; 19.09.2011
comment
@James в Indy: вы можете использовать функциональные возможности уровня файловой системы NTFS, такие как жесткие и программные ссылки, которые могут заставить файл появляться в каталоге, даже если на самом деле его там нет ... (это просто ссылка / указатель в фактический файл). Жесткая ссылка Google для NTFS или точки соединения NTFS - person marc_s; 19.09.2011

arrow_upward
2
arrow_downward

Вам по-прежнему понадобится web .config, поскольку есть элементы конфигурации, специфичные для Интернета, которых нет в app.config вашей службы. Как говорит Марк, использование атрибута ConfigSource позволит вам делиться общими элементы.

Обратите внимание, что элемент appSettings имеет небольшое отличие: атрибут File.

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

Это ведет себя иначе, чем атрибут ConfigSource, потому что вам не нужно заменять весь раздел внешним файлом, он может просто содержать элементы, которые вы хотите иметь дополнительно, или переопределить значения:

Вы можете использовать атрибут file, чтобы указать файл конфигурации, который предоставляет дополнительные параметры или переопределяет параметры, указанные в элементе appSettings.

Если вы используете ConfigSource для совместного использования других элементов, вы все равно будете иметь автоматический перезапуск приложения при изменении значений - примечание об атрибуте restartOnExternalChanges следует игнорировать для приложений ASP.NET, однако использование атрибута File будет означать, что изменения не вызовут перезапуск.

Содержимое внешних файлов по-прежнему должно быть кэшировано, поэтому это не повлияет на производительность.

person Zhaph - Ben Duguid    schedule 05.05.2009