Сплит-специфические и специфичные для клиента компоненты web.config

Question

У нас есть веб-приложение, работающее на месте у множества клиентов. Web.config содержит много

1. материал, который является «частью нашего приложения» (например, большинство <system.web> и <system.webServer> блоков) и
2. материал, который нужно настроить (строки подключения, настройки приложения, и различные пользовательские теги).

Во время обновлений часть 1 должна быть заменена, а часть 2 должна быть оставлена ​​как есть. В идеале у меня бы были web.app.config и web.custom.config, поэтому я могу заменить только первый. Разумеется, IIS должен был бы волшебным образом «объединить» те во время выполнения, чего он не делает.

я нашел следующие подходы:

• Put the custom stuff in external files, т.е. <appSettings configSource="appSettings.config"/>.

  Я не могу использовать это, потому что его можно использовать только для полных секций. Но, например, параметр aspnet:MaxHttpCollectionKeys является значением, которое should be controlled by the application, тогда как другие значения параметров приложения должны быть настраиваемыми.

• Parameterization or Web.Config Transformation.

  Я не могу использовать это, потому что наши клиенты имеют различные версии нашего приложения. Таким образом, мне нужно: заменить частями web.config, специфичными для приложения, а не преобразовывать отдельные теги. Кроме того, я бы хотел избежать добавления msdeploy в наш процесс развертывания (xcopy плюс некоторые скрипты для создания приложений IIS и их оптимальной работы в данный момент). О, и у меня все равно будет один большой web.config, связанный с конкретными приложениями и конкретными клиентами.

Есть ли какое-то элегантное решение, которое я пропустил?

Answer 1

Это правда, что configSource используется для полных разрезов, но appSettings имеет специальный атрибут называется file, который можно использовать для ссылки на файл, который будет «слито» в список AppSettings. См. https://msdn.microsoft.com/en-AU/library/ms228154(v=vs.85).aspx для более подробной информации. Я использовал экстенсивно, чтобы объединить файл appSettings.config со значениями, специфичными для среды - либо значения локального dev (как указано в репо), либо файл, который сбрасывается на сервер с настройками среды. Полезно при создании артефакта сборки через qa, uat, prod среды и т. Д. Для вас этот файл может содержать ваши конкретные значения для клиента и не будет меняться при развертывании обновлений.

Альтернативный подход состоит в том, чтобы реорганизовать конфигурацию вашего клиента в Custom Configuration Section. Также как вы набрали доступ к значениям конфигурации, вы можете загрузить его из раздела в web.config, загрузить его из раздела в файле web.config, который ссылается на другой файл через configSource, или вы можете загрузить его непосредственно из отдельный файл.

Затем вы можете оставить свою конфигурацию приложения в appSettings или переместить ее в отдельный раздел конфигурации.