web.config лучшие практики при обновлении

Question

Я отправляю приложение и позволяю клиентам вносить изменения в строки подключения и тому подобное в файле web.config.

При обновлении приложения это вызывает раздражение, поскольку я не хочу перезаписывать их значенияс моим.

Это особенно плохо, когда обновляются версии .net.

Как люди обычно справляются с ситуацией такого типа?

Например, как-то разбиваютweb.config, чтобы данные о клиентах больше не были частью этого?

Answer 1

Я никогда не слышал о том, чтобы кто-то делал web.config доступным и доступным для записи для клиентов или любого другого делового человека.Вы просто напрашиваетесь на неприятности.

Звучит так, как будто вы захотите разработать небольшую интерфейсную (веб) утилиту, которая позволит им отправлять значения в форме и сохранять в базе данных.Затем попросите ваше приложение обращаться к базе данных по этим значениям, а не к web.config.

Это похоже на проблему управления контентом.

Answer 2

У вас есть пара вариантов. Лучше всего, IMO, было бы не публиковать веб-конфигурации, когда вы помещаете приложение в их среду. Если необходимо написать новый раздел / параметр конфигурации, вы можете либо инкапсулировать некоторую логику, чтобы программно написать новую конфигурацию в небольшом вспомогательном приложении, и запустить ее как действие после развертывания, либо просто вставить новые параметры в файл e. -почта и отправить кому-то, кому вы доверяете, на другом конце, чтобы поместить его в конфиги. Я бы рекомендовал против второго варианта в 99% случаев; существует большой потенциал для пересечения проводов или просто для игнорирования, тогда это ваша вина, когда система выходит из строя, потому что конфиги не сделали это.

Answer 3

Разделите ваш файл конфигурации на две части.Один для вас, а другой для ваших клиентов.Все конфигурации, настраиваемые вашими клиентами, попадают в файл конфигурации клиента, а все остальное входит в ваш.

Это позволит вам легко обновить / изменить файл конфигурации без перезаписи ваших клиентов.

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

Я даже использовал его в в этом проекте для обнаружения изменений во внешних конфигурациях в ASP.NET.

Answer 4

Есть несколько способов справиться с этим. Я упомяну два. Один касается вашего процесса доставки. Другой на самом деле включает в себя web.config.

1) Не отправляйте файл web.config как «код». Считайте это «конфигурацией». Это не подходит для всех сценариев (на самом деле, сценарий на основе клиента - плохой сценарий, о котором я думал). Если вы осуществляете доставку в «производство», вы можете согласиться возложить на них ответственность за содержимое web.config (и есть хорошая попытка реорганизовать как можно больше в machine.config). Таким образом, такие вещи, как строка подключения, становятся проблемами производства, а не проблемами разработки.

2) Используйте атрибут configSource. ASP.NET 2.0 поддерживает внешние атрибуты с атрибутом configSource. Может быть трудно перевернуть ВСЕ из web.config как «производственную задачу» (в сценарии доставки клиенту они могут не быть экспертами во всем этом).

Итак, вы воплощаете это так. Вот ваш текущий раздел настроек приложения, например:

<appSettings>
  <add key="EnableFrobbing" value="false" />
  <add key="ExpectFooingFrom" value="fooingserver@domain.com " />
</appSettings>

Если это настройки, которые вы хотите экспортировать, чтобы ваши новые поставки не переопределяли настройки клиента, замените их следующим:

<appSettings configSource="App_Data\WebConfigXML\appSettings.xml"/>

Относительные пути только здесь, насколько я знаю.

Ссылки:

(Показывает, что свойство является новым в ASP.NET 2.0) http://msdn.microsoft.com/en-us/library/system.configuration.sectioninformation.configsource%28v=VS.80%29.aspx

http://www.codeproject.com/KB/aspnet/Manage_Webconfig.aspx

http://trycatchfail.com/blog/post/2008/09/25/Webconfig-magic-configSource-and-file-attributes.aspx