¿Cómo evitar que una aplicación ASP.NET se reinicie cuando se modifique web.config?
iis web-config (5)
Estoy alojando el tiempo de ejecución de ASP.NET a través del método ApplicationHost.CreateApplicationHost . Cuando web.config el web.config mientras la aplicación se está ejecutando, veo muchas oportunidades de primera ThreadAbortException s lanzadas. Esto es justo antes de que mi aplicación se caiga. Supongo que esto se debe a que el tiempo de ejecución ha detectado cambios en la configuración y quiere reiniciar.
Esto no es realmente un escenario soportado para nosotros, por lo que preferiría si pudiera simplemente apagar la recarga automática.
¿Alguien sabe como hacer esto?
Como mencionó jfburdet, la solución es usar waitChangeNotification y maxWaitChangeNotification.
Dicho esto, debe saber que no funcionan en IIS 7 si ASP.NET se ejecuta en modo mixto: http://forums.iis.net/t/1149344.aspx
En realidad, las primeras dos respuestas son incorrectas. Es posible, y bastante fácil, evitar que este reciclaje ocurra, y esta característica ha estado disponible desde al menos IIS6.
Método 1 (todo el sistema)
Cambie la configuración del registro DWORD para HKLM/SOFTWARE/Wow6432Node/Microsoft/ASP.NET/FCNMode por el valor 1 , que deshabilitará todas las notificaciones de cambio de archivos.
No se deje confundir por la ubicación: Wow6432Node tiene, en este caso, ninguna influencia en el bitness de su aplicación web.
Método 2 (.NET 4.5+)
Si está usando .NET 4.5, ahora es posible deshabilitar esto en un nivel por sitio , simplemente use lo siguiente en su web.config :
<httpRuntime fcnMode="Disabled"/>
Método 3 (IIS6 +)
Finalmente, y también (al menos) desde IIS6, hay una configuración llamada DisallowRotationOnConfigChange como configuración solo para el grupo de aplicaciones (al menos eso es lo que creo que el texto en MSDN trata de decir, pero no lo he probado). Establézcalo en true y los cambios en la configuración del grupo de aplicaciones no darán lugar a un reciclaje inmediato.
Esta última configuración también se puede establecer desde Configuración avanzada del grupo de aplicaciones:
Método 4 (ASP.NET 1.0 y 1.1)
Para los sitios web (antiguos) que usan ASP.NET 1.0 o 1.1, existe un error confirmado que puede causar reciclamientos rápidos y repetidos en los cambios de archivos. La solución temporal en ese momento era similar a la sugerida por MartinHN en la pregunta principal, es decir, algo así como lo siguiente en su web.config :
<compilation
debug="false"
defaultLanguage="vb"
numRecompilesBeforeAppRestart="5000">
Esto no inhabilita el reciclaje, pero lo hace solo después de que se hayan realizado 5000 recompilaciones. Si este número es útil depende del tamaño de su aplicación. Microsoft no dice claramente qué es realmente una recompilación . El valor predeterminado, sin embargo, es 15 .
Como comentario aparte: independientemente de la versión de .NET o Windows, encontramos que cuando la aplicación se ejecuta desde un recurso compartido y se utiliza en un entorno de equilibrio de carga, el sitio recicla continuamente. La única forma de resolverlo era agregando esa configuración de FNCMode al registro (pero ahora hay más opciones de grano fino).
Me encontré con un problema aún mayor en la misma línea: los cambios en cualquier archivo o subcarpeta en el directorio base de AppDomain hacen que se cierre el entorno de alojamiento. Este es un gran problema para nuestra aplicación ya que estamos ejecutando una interfaz de usuario de WPF en el mismo dominio de aplicación y no podemos reiniciarlo sin ser desconfiables con el usuario.
Realmente quería evitar tener que ejecutar un AppDomain separado para la parte de la aplicación basada en web, así que investigué un poco con Reflector. Descubrí que el culpable era la clase interna FileChangesMonitor .
Así que escribí un horrible truco de reflexión horrible para resolver el problema. Pensé en publicarlo aquí como una posible solución para cualquier otra persona que tenga el mismo problema. Solo necesita llamar a HttpInternals.StopFileMonitoring() para deshabilitar el apagado de los cambios de archivos / carpetas.
internal static class HttpInternals
{
private static readonly FieldInfo s_TheRuntime = typeof(HttpRuntime).GetField("_theRuntime", BindingFlags.NonPublic | BindingFlags.Static);
private static readonly FieldInfo s_FileChangesMonitor = typeof(HttpRuntime).GetField("_fcm", BindingFlags.NonPublic | BindingFlags.Instance);
private static readonly MethodInfo s_FileChangesMonitorStop = s_FileChangesMonitor.FieldType.GetMethod("Stop", BindingFlags.NonPublic | BindingFlags.Instance);
private static object HttpRuntime
{
get
{
return s_TheRuntime.GetValue(null);
}
}
private static object FileChangesMonitor
{
get
{
return s_FileChangesMonitor.GetValue(HttpRuntime);
}
}
public static void StopFileMonitoring()
{
s_FileChangesMonitorStop.Invoke(FileChangesMonitor, null);
}
}
Una solución sería agregar el siguiente elemento a la sección web.config:
<httpRuntime
waitChangeNotification="315360000"
maxWaitChangeNotification="315360000"
/>
Por lo que sé, no hay forma de deshabilitar este comportamiento, los cambios en la configuración web obligan a reiniciar la aplicación.
Actualización: en realidad es posible, hay una serie de métodos, bien documentados, como se explica en esta respuesta *
Respuesta original:
Hay una pregunta similar here solo para otra referencia. Encontré información adicional que puede ser útil.
Los cambios de configuración provocan un reinicio del dominio de la aplicación
Los cambios en la configuración de los archivos Web.config hacen que el dominio de la aplicación se reinicie indirectamente. Este comportamiento ocurre por diseño. Opcionalmente, puede usar el atributo configSource para hacer referencia a los archivos de configuración externos que no provocan un reinicio cuando se realiza un cambio. Para obtener más información, consulte configSource en Atributos generales heredados por elementos de sección.
* Descargo de responsabilidad: escribí la otra respuesta y normalmente no haría una autorreferencia, pero creo que es lo suficientemente relevante como para vincularla aquí, ya que 8 años después de esta publicación es bastante diferente: una solución es muy fácil al hacer clic en el frente de IIS final y soluciones temporales desde ASP.NET 1.0.