Как остановить наследование <configSections> в Web.Config

Вы просто не можете использовать <location path="." inheritInChildApplications="false"> в определенных частях вашего web.config, чтобы сказать ему игнорировать наследование определенных разделов (вы получите ошибки, такие как атрибут inheritInChildApplications не объявлен, и так четвертый, если вы попытаетесь помещая его в разделы, где он не поддерживается).

Например, вы не можете использовать его до или внутри <configSections>. Вы можете, например, обернуть тэг <system.web> в тег location, но мне нужно остановить наследование чего-либо в <configSections>, и я не вижу способа сделать это.

Мое вспомогательное приложение наследует некоторые из тех же конфигурационных параметров, что и моя веб-конфигурация родительского приложения в IIS 7 в дереве. Я не вижу возможности помещать <clear/> в тег configSecion, поскольку это недопустимый тег, если вы попытаетесь добавить его там.

Как вы говорите, чтобы игнорировать этот раздел?

Ответы

Ответ 1

Этот же вопрос задавался несколько раз на SO, а также на многих других форумах, и ответ был более или менее одинаковым. Нет, вы не можете использовать location/clear/remove для configsection.

Microsoft даже ответила на свою нить следующим образом.

Отправлено Microsoft 7/23/2009 в 5:40 вечера

 <clear /> and <remove />

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

Мы рассмотрели возможность добавления этого типа функциональности для выпуска VS 2010, но мы решили против него по двум причинам.

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

Вторая причина заключается в том, что обычно обработчики разделов и определения групп разделов производятся в двух разных местах: начальный набор регистраций в корневых файлах конфигурации, а затем добавочный набор регистраций на уровне приложения web.config. Это не означает, что сценарий, когда разработчик хочет изменить определения обработчиков, недействителен - это просто сценарий с низким правдоподобием. Благодарим вас за то, что нашли время, чтобы отправить свое предложение через Connect!

Проверьте этот поток SO, в котором простые состояния избегают использования конфликтующих групп разделов.

Однако, Наирман предлагает следующее,

Я не уверен, что вы можете иметь один и тот же раздел, определенный по-разному в подпапке; вы можете сделать эту подпапку автономным виртуальным приложением, и в этом случае она не наследует ни одного из параметров родителя; в этом случае он также будет выполняться в своем собственном пуле приложений; если у вас нет зависимостей InProc, этот параметр также

Как предотвратить наследование файла web.config для" configSections "?

Ответ 2

Подтвердите это для этого ответа stackoverflow: "Запись уже добавлена ​​" - Два отдельных пула приложений

Включено сюда, поэтому я не жалуюсь на...

Отредактируйте C:\Windows\System32\inetsrv\config\applicationHost.config, чтобы добавить

enableConfigurationOverride="false"

Для каждого пула приложений, которые не должны наследовать настройки web.config от родителя. Это проявилось для меня следующим образом:

Существует раздел дубликата 'system.web.extensions/scripting/scriptResourceHandler', который определен

Если вы хотите запускать приложения .NET4 (даже в виде отдельных приложений и пулов) под родительским приложением .NET2, то это кажется единственным жизнеспособным решением.

В качестве примера записи пула приложений в applicationHost.config, которая включает это свойство:

<add name="MyApplicationPool" autoStart="true" managedRuntimeVersion="v4.0" enableConfigurationOverride="false">
<processModel identityType="ApplicationPoolIdentity" />
</add>

Ответ 3

Что вы можете сделать, так это сделать эту папку приложением, сделать обратный прокси (с использованием модуля повторного URL-адреса IIS 7) на другом внутреннем сайте и полностью сохранить отдельные конфигурации.

Например, один из наших для перенаправления прокси-сервера: Соответствует шаблону с помощью подстановочных знаков * для перезаписи URL http://127.0.0.1:8080/ {R: 1}

Страшная идея быть честным (я ненавижу грязные методы достижения цели), вы должны быть в состоянии сказать IIS, что вы хотите, чтобы чистый сланец в конфигурации дочернего приложения.