asp.net - declarar - web.config configuration file error

Cómo detener la herencia de<configSections> en Web.Config (3)

Esta misma pregunta se hizo varias veces en SO, así como en muchos otros foros y la respuesta fue más o menos la misma. No, no puede usar la ubicación / borrar / eliminar para la configuración.

Microsoft incluso respondió en su hilo de la siguiente manera.

Publicado por Microsoft el 23/7/2009 a las 5:40 p.m.

<clear /> and <remove />

nunca se implementaron para configSections y sectionGroups debido a la dificultad que implica el intento de fusionar diferentes definiciones de los mismos manejadores de sección y grupos de sección.
Consideramos agregar este tipo de funcionalidad para la versión VS 2010, pero decidimos no hacerlo por dos razones.
El primero es la complejidad adicional que trae, en gran parte porque los manejadores de sección y los grupos de sección se utilizan para iniciar el sistema de configuración. Como resultado, permitir la fusión de la semántica en el medio de la inicialización del sistema de configuración es un problema no trivial que resolver.
La segunda razón es que generalmente los manejadores de secciones y las definiciones de grupos de secciones se crean en dos lugares distintos: un conjunto inicial de registros en los archivos de configuración raíz y luego un conjunto aditivo de registros en el nivel de aplicación web.config. Eso no significa que un escenario en el que un desarrollador quiera modificar definiciones de manejador no sea válido; es solo un escenario de baja probabilidad. ¡Gracias por tomarse el tiempo para enviar su sugerencia a través de Connect!

Consulte este hilo SO, cuyos estados simples evitan el uso de grupos de secciones en conflicto.

Sin embargo, Nairman sugiere seguir,

No estoy seguro de que pueda tener la misma sección definida de manera diferente en una subcarpeta; podría hacer que esa subcarpeta fuera una aplicación virtual independiente, en cuyo caso no heredaría ninguna de las configuraciones del elemento primario; en este escenario, también se ejecutaría en su propio grupo de aplicaciones; si no tienes dependencias InProc, esa es una opción también

¿Cómo prevenir la herencia del archivo web.config para "configSections"?

Simplemente no puedes usar <location path="." inheritInChildApplications="false"> <location path="." inheritInChildApplications="false"> en ciertas partes de tu web.config para decirle que ignore la herencia de ciertas secciones (obtendrás errores como "el atributo inheritInChildApplications no está declarado" y, por tanto, el cuarto si intentas ponerlo en secciones donde no es compatible).

Por ejemplo, no puede usarlo antes o dentro de <configSections> . Puede, por ejemplo, ajustar su etiqueta <system.web> en la etiqueta de ubicación, pero necesito detener la herencia de cualquier cosa en <configSections> y no veo una manera de hacerlo.

Mi aplicación secundaria hereda algunas de las mismas configuraciones que la configuración web de mi aplicación principal en IIS 7 en el árbol. No veo forma de poner un <clear/> en la etiqueta configSecion ya que es una etiqueta no válida si intentas agregarla allí.

¿Cómo le dices que ignore esa sección?

Gracias por esta respuesta a : "La entrada ya se ha agregado": dos grupos de aplicaciones independientes

Incluido aquí, así que no me quejo en ...

Edite C: / Windows / System32 / inetsrv / config / applicationHost.config para agregar

enableConfigurationOverride="false"

Para cada uno de los grupos de aplicaciones que no deberían heredar la configuración web.config del padre. Esto se manifestó para mí como el siguiente:

Hay una sección duplicada ''system.web.extensions / scripting / scriptResourceHandler'' definida

Si desea ejecutar aplicaciones .NET4 (incluso como aplicaciones y grupos separados) en una aplicación principal .NET2, esta parece ser la única solución viable.

Como una entrada de grupo de aplicaciones de ejemplo en applicationHost.config que incluye esta propiedad:

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

Lo que podría hacer es convertir esa carpeta en una aplicación, hacer un proxy inverso (utilizando el módulo de reescritura de URL de IIS 7) en otro sitio interno y mantener las configuraciones completamente separadas.

Por ejemplo, uno de los nuestros para una redirección de proxy es: Coincide con el patrón usando comodines * para reescribir la URL http://127.0.0.1:8080/ {R: 1}

Una idea terrible para ser sincero (odio los métodos sucios de hacer las cosas), deberías poder decirle a IIS que quieres borrar la configuración de la aplicación de un niño.