Comment arrêter l'héritage de <configSections> dans Web.Config

Question

Vous ne pouvez tout simplement pas utiliser <location path="." inheritInChildApplications="false"> dans certaines parties de votre web.config afin de lui indiquer d'ignorer l'héritage de certaines sections (vous obtiendrez des erreurs telles que "inheritInChildApplications attribute is not declared" et ainsi de suite si vous essayez de le placer dans des sections où il n'est pas pris en charge).

Par exemple, vous ne pouvez pas l'utiliser avant ou à l'intérieur de <configSections> . Vous pouvez par exemple envelopper votre <system.web> dans la balise d'emplacement mais j'ai besoin d'arrêter l'héritage de n'importe quel élément de la balise <configSections> et je ne vois pas de moyen de le faire.

Ma sous-application hérite de certains des paramètres de configuration que la configuration Web de l'application parentale contient dans la section IIS 7 dans l'arbre. Je ne vois aucun moyen de mettre un <clear/> soit dans la balise configSecion car c'est une balise invalide si vous essayez de l'ajouter là.

Comment pouvez-vous lui dire d'ignorer cette section ?

Answer 1

Cette même question a été posée plusieurs fois sur SO ainsi que sur de nombreux autres forums et la réponse était plus ou moins la même, Non vous ne pouvez pas utiliser location/clear/remove pour configsection.

Microsoft a même répondu sur leur fil de discussion comme suit.

Posté par Microsoft le 7/23/2009 à 5:40 PM

 <clear /> and <remove />

n'ont jamais été implémentées pour configSections et sectionGroups en raison de la difficulté de fusionner différentes définitions des mêmes section-handlers et sectionGroups.

Nous avons envisagé d'ajouter ce type de fonctionnalité pour la version VS 2010, mais nous avons décidé de ne pas le faire pour deux raisons.

La première est la complexité supplémentaire qu'elle apporte, en grande partie parce que les gestionnaires de sections et les groupes de sections sont utilisés pour amorcer le système de configuration. Par conséquent, permettre la sémantique de fusion au milieu de l'amorçage du système de configuration est un problème non trivial à résoudre.

La deuxième raison est qu'en général, les gestionnaires de section et les définitions de groupes de sections sont effectués à deux endroits distincts - un ensemble initial d'enregistrements dans les fichiers de configuration de la racine, puis un groupe de sections. additif ensemble d'enregistrements dans le web.config au niveau de l'application. Cela ne signifie pas qu'un scénario dans lequel un développeur veut modifier les définitions des gestionnaires n'est pas valable - c'est juste un scénario à faible probabilité. Merci cependant d'avoir pris le temps de soumettre votre suggestion via Connect !

---

Consultez ce fil de discussion sur le SO, qui indique simplement qu'il faut éviter d'utiliser des groupes de sections contradictoires.

Cependant, Nairman suggère ce qui suit,

Je ne suis pas sûr que vous puissiez avoir la même section définie différemment dans un sous-dossier ; vous pourriez faire de ce sous-dossier une application virtuelle autonome, auquel cas elle n'hériterait d'aucun des paramètres du parent ; dans ce scénario, elle s'exécuterait également dans son propre pool d'applications ; si vous n'avez pas de dépendances InProc, c'est également une option possible.

Comment empêcher l'héritage du fichier web.config pour "configSections" ?

Answer 2

Le mérite en revient à cette réponse de stackoverflow : "L'entrée a déjà été ajoutée" - Deux pools d'applications distincts

Je l'ai inclus ici pour ne pas me faire plaindre...

Modifier le C:\Windows\System32\inetsrv\config\applicationHost.config à ajouter

enableConfigurationOverride="false"

Pour chacun des pools d'applications qui ne doivent pas hériter des paramètres web.config du parent. Cela s'est manifesté pour moi de la manière suivante :

Il existe un doublon de la section 'system.web.extensions/scripting/scriptResourceHandler'.

Si vous souhaitez exécuter des applications .NET4 (même en tant qu'applications et pools séparés) sous une application mère .NET2, cela semble être la seule solution viable.

Voici un exemple d'entrée de pool d'applications dans applicationHost.config qui inclut cette propriété :

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

Answer 3

Ce que vous pouvez faire, c'est faire de ce dossier une application, créer un proxy inverse (à l'aide du module URL Rewrite d'IIS 7) vers un autre site interne et les configurations devraient être complètement séparées.

Par exemple, l'un des nôtres pour une redirection par proxy est : Correspond au modèle en utilisant les caractères génériques * pour réécrire l'URL. http://127.0.0.1:8080/ {R:1}

Une idée terrible pour être honnête (je déteste les méthodes sales pour faire les choses), vous devriez être capable de dire à IIS que vous voulez faire table rase de la configuration d'une application enfant.

Answer 4

Vous ne pouvez pas changer l'emplacement de ConfigSections car il s'agit d'une section spéciale qui indique à ASP.net comment traiter les paramètres d'un fichier de configuration.

Vous ne devriez pas avoir de conflits dans ConfigSections parce qu'il n'y a que des pointeurs vers d'autres parties de l'arbre. Web.Config .