Избегайте наследования web.config в дочерних веб-приложениях с помощью inheritInChildApplications


153

Я пытаюсь добавить

<location inheritInChildApplications="false">

в web.config моего родительского веб-приложения, но, похоже, он не работает.

У моих родителей web.configесть:

<configuration>
    <configSections>
    </configSections>

    // 10 or so custom config sections like log4net, hibernate,

    <connectionStrings>
    </connectionStrings>

    <appSettings>
    </appSettings>

    <system.diagnostics>
    </system.diagnostics>

    <system.web>
         <webParts>
         </webParts>
         <membership>
         </membership>

         <compilation>
         </compilation>
    </system.web>

    <location ..>
    <system.web>
        </system.web>
    </location>

    <system.webServer>
    </system.webServer>

Моё дочернее веб-приложение настроено как приложение в IIS и наследуется от родительского, web.configчто вызывает проблемы.

Где именно я должен разместить

<location inheritInChildApplications="false">

поэтому он игнорирует все различные настройки web.config?

Ответы:


203

Как упоминалось в комментариях к предыдущему ответу, вы не можете просто добавить строку ...

<location path="." inheritInChildApplications="false">

... чуть ниже <configuration>. Вместо этого вам нужно обернуть отдельные разделы web.config, для которых вы хотите отключить наследование. Например:

<!-- disable inheritance for the connectionStrings section -->
<location path="." inheritInChildApplications="false">
   <connectionStrings>
   </connectionStrings>
</location>

<!-- leave inheritance enabled for appSettings -->
<appSettings>
</appSettings>

<!-- disable inheritance for the system.web section -->
<location path="." inheritInChildApplications="false">
   <system.web>
        <webParts>
        </webParts>
        <membership>
        </membership>

        <compilation>
        </compilation>
      </system.web>
 </location>

Хотя <clear />может работать для некоторых разделов конфигурации, есть некоторые, которые вместо этого требуют <remove name="...">директивы, а третьи, похоже, тоже не поддерживают. В этих ситуациях, вероятно, целесообразно установить inheritInChildApplications="false".


11
Можно ли сделать это наоборот? Мне кажется странным, что я должен обновить родителя, когда именно ребенок решает, должны ли настройки быть унаследованы или нет.
nabeelfarid

@nabeelfarid - я полностью согласен. Если у вас есть WordPress блог внутри .NET-приложения со сложным web.config, это может быть огромной болью, связанной с его очисткой или предотвращением наследования. Я думаю, что вся система 'местоположения' больше ориентирована на безопасность для общих хостов, что для проблем совместимости, для которых большинство людей находят себя здесь
Simon_Weaver

Это не работает для меня? Есть предположения? У меня есть служба wcf, в которой для родительского конфига установлено соединение с базой данных SIT. У меня есть другая папка в той же службе, которая говорит «QA», и она содержит те же файлы службы WCF, что и в SIT, включая web.config, но указывает базу данных на QA. Когда я вызываю службу wcf внутри папки «QA», она берет соединение только из родительского конфига (даже я даю тег <location>). Пожалуйста, дайте мне знать, в чем проблема.
Суперачу

@NickCecil, как мне добиться этого в IIS 6? inheritInChildApplicationsне принимается в качестве допустимого параметра для <location />элемента. Мой сайт работает под управлением SharePoint (2007). Я создал приложение в виртуальном каталоге на этом веб-сайте, управляемом собственным пулом приложений. Тем не менее, я сталкиваюсь с конфликтами между конфигурацией SharePoint и этим приложением. Посмотрите этот вопрос, который я опубликовал в разделе Ошибка сервера
Веб-пользователь

1
Мое приложение, которое я создал как дочерний элемент веб-сайта, все еще хочет загрузить библиотеки DLL с родительского веб-сайта. Видимо, я не могу использовать <location>во время выполнения ...
Фрэнсис Дюшарм

65

Он должен идти прямо под корневым <configuration>узлом, и вам нужно установить путь следующим образом:

<?xml version="1.0"?>
<configuration>
    <location path="." inheritInChildApplications="false"> 
        <!-- Stuff that shouldn't be inherited goes in here -->
    </location>
</configuration>

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

<?xml version="1.0"?>
<configuration>
    <connectionStrings>
        <clear/>
        <!-- Child config's connection strings -->
    </connectionStrings>
</configuration>

17
Я получаю эту ошибку «Невозможно прочитать раздел конфигурации« configSections », потому что в нем отсутствует объявление раздела» в файле моих родителей web.config.
Blankman

Можете ли вы опубликовать свой конфиг с элементом <location>? Я также проверил бы мои изменения и посмотрел, может ли <clear /> быть лучшим подходом к тому, что вы пытаетесь сделать.
Эндрю Харе

6
это не работает, когда вы помещаете это прямо под <конфигурация>. Вы можете обернуть, скажем, узел <system.web>, но вы не можете просто поместить его в корень следующим образом.
PositiveGuy

Если вы поместите его в <configuration> в качестве 2-го узла, вы получите «атрибут attributeitInChildApplications не объявлен». Так что это недопустимый атрибут на этом уровне в web.config. Так как вы можете сказать, что это сработало?
PositiveGuy

12
-1: я также могу подтвердить, что использование элемента location, как показано выше, НЕ работает.
Адриан Григоре

23

Я положил все в:

<location path="." inheritInChildApplications="false">
....
</location>

за исключением: <configSections/>, <connectionStrings/>и <runtime/>.

В некоторых случаях мы не хотим наследовать некоторые разделы от <configSections />, но мы не можем поместить <section/>тег в <location/>, поэтому мы должны создать <secionGroup />и поместить нежелательные разделы в эту группу. Группы разделов могут быть позже вставлены в тег местоположения.

Поэтому мы должны изменить это:

<configSections>
  <section name="unwantedSection" />
</configSections>

В:

<configSections>
  <sectionGroup name="myNotInheritedSections">
    <section name="unwantedSection" />
  </sectionGroup>
</configSections>

<location path="." inheritInChildApplications="false">
    <myNotInheritedSections>
        <unwantedSection />
    </myNotInheritedSections>
</location>

У меня есть пользовательские разделы
Kiquenet

Это решило мою проблему. У меня было веб-приложение с EF6.1.3 и дочернее веб-приложение с EF5. Обновление дочернего веб-приложения не могло быть и речи, поэтому мне пришлось использовать эту технику, чтобы она работала, и она работала. Я последовал этому примеру, изменение myNotInheritedSectionsк ef6Privateи unwantedSectionявляется entityFrameworkраздел.
Мохамед Нуур

Можете ли вы помочь, почему мой не работает, вот мой код <configSections> <sectionGroup name="ef6Private"> <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" /> </sectionGroup> </configSections> <location path="." inheritInChildApplications="false"> <ef6Private> <entityFramework /> </ef6Private> </location>
asteriskdothmg

9

Мы получили ошибку, связанную с этим, после недавнего выпуска кода в одну из наших сред разработки. У нас есть приложение, которое является дочерним по отношению к другому приложению. Эти отношения работали нормально в течение ЛЕТ до вчерашнего дня.

Проблема:
мы получили желтую ошибку трассировки стека из-за ввода повторяющихся ключей. Это связано с тем, что ключ web.config для дочернего и родительского приложений имел этот ключ. Но это существовало многие годы без изменений. Почему вдруг это проблема сейчас?

Решение:
причина, по которой это никогда не было проблемой, заключается в том, что значения ключей И всегда были одинаковыми. Вчера мы обновили наши строки подключения SQL, чтобы включить Имя приложения в строку подключения. Это сделало строку уникальной и внезапно начала проваливаться.

Без каких-либо исследований точной причины этого, я должен предположить, что, когда дочернее приложение наследует значения родителей web.config, оно игнорирует идентичные пары ключ / значение.

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

    <location path="." inheritInChildApplications="false">
        <connectionStrings>
            <!-- Updated connection strings go here -->
        </connectionStrings>
    </location>

Изменить: я забыл упомянуть, что я добавил это в PARENTS web.config. Мне не нужно было изменять web.config ребенка.

Спасибо всем за помощь в этом, спас наши окурки.


6

Если (насколько я понимаю) вы пытаетесь полностью заблокировать наследование в веб-конфигурации вашего дочернего приложения, я предлагаю вам избегать использования тега в файле web.config. Вместо этого создайте новый пул приложений и отредактируйте файл applicationHost.config (расположенный в% WINDIR% \ System32 \ inetsrv \ Config и% WINDIR% \ SysWOW64 \ inetsrv \ config). Вам просто нужно найти запись для вашего apppool и добавить атрибут, enableConfigurationOverride="false"как в следующем примере:

<add name="MyAppPool" autoStart="true" managedRuntimeVersion="v4.0" managedPipelineMode="Integrated" enableConfigurationOverride="false">
    <processModel identityType="NetworkService" />
</add>

Это позволит избежать наследования конфигурации в приложениях, обслуживаемых MyAppPool.

Matteo


1
MSDN говорит: «При значении false все настройки в файлах Web.config будут игнорироваться для этого пула приложений», и это просто не похоже на то, что вы думаете, что это значит. Мне бы очень хотелось, чтобы это был правильный ответ, но я просто не могу заставить его работать. Мне кажется, что этот параметр означает «полностью запретить локальный web.config для этого приложения»
Simon_Weaver

Таким образом, в основном приложения в этом пуле приложений должны работать без файла web.config? Я понимаю, что "игнорируется web.config" в корневой папке. Я использовал это несколько раз успешно. Убедитесь, что дочернее приложение не зависит от конфигураций в корневом web.config (попробуйте запустить дочернее приложение в отдельной корневой папке).
Маттео Сганзетта

1
Вы также можете проверить метод № 2 на этой странице, хотя я не проверял его iislogs.com/steveschofield/2009/09/20/…
Маттео Сганзетта

мое дочернее приложение на самом деле является точной копией родительского приложения. Я хочу быть в состоянии поставить /previewтак, чтобы люди могли протестировать новую версию, прежде чем делать это в живую. Все всегда предлагают <location>для решения этой проблемы, поэтому я был очень рад прочитать ваш пост. Однако он жалуется The entry 'default' has already been added.на запись конфигурации, связанную с AppFabric, даже когда я используюenableConfigurationOverride="false"
Simon_Weaver

Кроме того, если я установлю enableConfigurationOverride="false"на свое корневое приложение, оно полностью
уничтожит


1

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

Короче говоря, наш корневой веб-сайт - ASP.NET 3.5 (версия 2.0 с добавлением определенных библиотек), и у нас есть подпрограмма ASP.NET 4.0.

Наследование web.config заставляет вложенное приложение ASP.NET 4.0 наследовать файл web.config родительского приложения ASP.NET 3.5.

Однако глобальное (или «корневое») приложение ASP.NET 4.0 web.config, которое находится в C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Config \ web.config и C: \ Windows \ Microsoft. NET \ Framework64 \ v4.0.30319 \ Config \ web.config (в зависимости от вашей разрядности), уже содержит эти разделы конфигурации.

Затем приложение ASP.NET 4.0 пытается объединить корневой web.config ASP.NET 4.0 и родительский web.config (тот, что для приложения ASP.NET 3.5) и работает с дубликатами в узле.

Единственное решение, которое мне удалось найти, - это удалить разделы конфигурации из родительского web.config, а затем либо

  1. Определите, что они вам не нужны в вашем корневом приложении, или если вы это делаете
  2. Обновите родительское приложение до ASP.NET 4.0 (чтобы оно получило доступ к корневым файлам config.eff config).
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.