Comment arrêter l'héritage de <configSections> dans Web.Config
Vous ne pouvez simplement pas utiliser <location path="." inheritInChildApplications="false"> dans certaines parties de votre web.config afin de lui dire d'ignorer l'héritage de certaines sections (vous obtiendrez des erreurs telles que "l'attribut inheritInChildApplications n'est pas déclaré" et donc en quatrième position si vous essayez de le placer dans des sections où ce n'est pas supporté).
Par exemple, vous ne pouvez pas l'utiliser avant ou dans <configSections>. Vous pouvez par exemple envelopper votre balise <system.web> dans la balise d'emplacement, mais je dois arrêter l'héritage de quoi que ce soit dans <configSections> et je ne vois pas comment y parvenir.
Ma sous-application hérite des mêmes paramètres de configuration que la configuration Web de mon application parent dans IIS 7 dans l'arborescence. Je ne vois aucun moyen de mettre un <clear/> non plus dans la balise configSecion car c'est une balise non valide si vous essayez de l'ajouter ici.
Comment lui dites-vous d'ignorer cette section?
Cette même question a été posée à plusieurs reprises sur SO ainsi que sur de nombreux autres forums et la réponse a été à peu près la même. Non, vous ne pouvez pas utiliser location/clear/remove pour la configuration.
Microsoft a même répondu sur leur fil comme suit.
Publié par Microsoft le 23/07/2009 à 17h40
<clear /> and <remove />
n'ont jamais été implémentés pour configSections et sectionGroups en raison de la difficulté à tenter de fusionner différentes définitions des mêmes gestionnaires de section et groupes de section.
Nous avons envisagé d’ajouter ce type de fonctionnalité à la version VS 2010, mais nous nous sommes prononcés contre pour deux raisons.
Le premier est la complexité supplémentaire qu'il apporte, en grande partie parce que les gestionnaires de section et les groupes de section sont utilisés pour amorcer le système de configuration. En conséquence, permettre la sémantique de fusion en cours de démarrage du système de configuration est un problème non trivial à résoudre.
La deuxième raison est que les gestionnaires de section et les définitions de groupe de section sont généralement placés à deux endroits distincts: un premier ensemble d’enregistrements dans les fichiers de configuration racine, puis un additive ensemble d’enregistrements au niveau de l’application web.config . Cela ne signifie pas qu'un scénario dans lequel un développeur souhaite modifier les définitions de gestionnaire n'est pas valide, il s'agit simplement d'un scénario peu probable. Merci d'avoir pris le temps de soumettre votre suggestion via Connect!
Découvrez ce thread SO, dont les états simples évitent l'utilisation de groupes de sections en conflit.
Cependant, Nairman suggère de suivre,
Je ne suis pas sûr que vous puissiez avoir la même section définie différemment dans un sous-dossier; vous pouvez faire de ce sous-dossier une application virtuelle autonome, auquel cas il n'héritera d'aucun des paramètres du parent; dans ce scénario, il serait également exécuté dans son propre pool d'applications; si vous n'avez pas de dépendances InProc, c'est aussi une option
Comment empêcher l'héritage pour le fichier web.config pour "configSections"?
Cela tient à cette réponse à la pile de flux: "Une entrée a déjà été ajoutée" - Deux pools d'applications distincts
Inclus ici pour ne pas me plaindre à ...
Editez le fichier 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 comme suit:
Il y a une copie de la section 'system.web.extensions/scripting/scriptResourceHandler' définie
Si vous souhaitez exécuter des applications .NET4 (même sous forme d'applications et de pools distincts) sous une application parent .NET2, il semble que ce soit la seule solution viable.
A titre d'exemple, l'entrée du 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>
Ce que vous pourriez faire, c’est faire de ce dossier une application, faire un proxy inverse (en utilisant le module de réécriture de l’URL de IIS 7) sur un autre site interne et conserver les configurations complètement séparées.
Par exemple, l’une des nôtres pour une redirection de proxy est la suivante: Correspond au modèle en utilisant des 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 avancer les choses), vous devriez pouvoir dire à IIS que vous voulez une table rase sur la configuration d'une application enfant.