¿Cómo evitar que se reinicie una aplicación ASP.NET cuando se modifica web.config?

Question

Estoy alojando el tiempo de ejecución ASP.NET a través del método ApplicationHost.CreateApplicationHost . Cuando modifico el web.config mientras la aplicación se está ejecutando, veo muchas oportunidades de ThreadAbortException de primera oportunidad. 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 desea reiniciarse.

Este no es realmente un escenario compatible para nosotros, por lo que preferiría si pudiera apagar la recarga automática.

¿Alguien sabe cómo hacer esto?

Answer 1

Por lo que sé, no hay forma de deshabilitar este comportamiento, los cambios en el webconfig obligan a reiniciar la aplicación.

Actualización: en realidad es posible, hay varios métodos, bien documentados, como se explica en esta respuesta *

Respuesta original:

Hay una pregunta similar aquí solo para otra referencia. Encontré información adicional que puede ser útil.

  

Los cambios de configuración provocan un reinicio   del dominio de aplicación
  Cambios a   Ajustes de configuración en Web.config   archivos indirectamente causan la aplicación   dominio para reiniciar. Este comportamiento   ocurre por diseño. Usted puede opcionalmente   usar el atributo configSource para   archivos de configuración externa de referencia   que no provocan un reinicio cuando un   Se realiza el cambio. Para más información,   ver configSource en Atributos generales   Heredado por elementos de sección.

De este artículo de MSDN

* ^{Descargo de responsabilidad: escribí la otra respuesta y normalmente no haría una referencia propia, pero me parece lo suficientemente relevante como para vincular aquí desde 8 años después de esta publicación, es realmente muy diferente: una solución es muy fácil Al hacer clic en el front-end de IIS, existen soluciones alternativas desde ASP.NET 1.0.}

Answer 2

En realidad, las dos primeras respuestas son incorrectas. Es posible , y bastante fácil, evitar que ocurra este reciclaje, y esta función ha estado disponible desde al menos IIS6.

Método 1 (en todo el sistema)

Cambie la configuración de registro DWORD para HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ ASP.NET \ FCNMode al valor 1 , que será deshabilitar todas notificaciones de cambios de archivos.

No se deje confundir por la ubicación: Wow6432Node no tiene, en este caso, ninguna influencia en el bitness de su aplicación web.

Método 2 (.NET 4.5+)

Si está utilizando .NET 4.5, entonces ahora es posible desactivar esto en un por nivel de 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 una configuración solo para el grupo de aplicaciones (al menos eso es lo que creo que el texto en MSDN intenta decir, pero no lo he probado eso). Establézcalo en true y los cambios en la configuración del grupo de aplicaciones no darán como resultado 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 sitios web (antiguos) que usan ASP.NET 1.0 o 1.1, hay un error confirmado que puede causar reciclados rápidos y repetidos en los cambios de archivos. La solución en ese momento era similar a lo que MartinHN sugirió en la pregunta principal, es decir, algo como lo siguiente en su web.config :

<compilation 
   debug="false"
   defaultLanguage="vb"
   numRecompilesBeforeAppRestart="5000">

Esto no desactiva el reciclaje, pero lo hace solo después de que se hayan realizado las recompilaciones 5000 . Si este número es útil depende del tamaño de su aplicación. Microsoft no dice claramente qué es realmente una recompilación . Sin embargo, el valor predeterminado es 15 .

Como nota aparte: independientemente de la versión de .NET o Windows, encontramos que cuando la aplicación se ejecuta desde un recurso compartido y se usa en un entorno de carga equilibrada, el sitio se recicla continuamente. La única forma de resolverlo fue agregar la configuración de FNCMode al registro (pero ahora hay más opciones detalladas).

Answer 3

Me encontré con un problema aún mayor en la misma línea: los cambios en cualquier archivo o subcarpeta en el directorio base del dominio de aplicación hacen que el entorno de alojamiento se cierre. Este es un problema bastante grande para nuestra aplicación, ya que estamos ejecutando una interfaz de usuario de WPF en el mismo dominio de aplicación y no podemos reiniciarla sin distraer al usuario.

Realmente quería evitar tener que ejecutar un AppDomain separado para la parte de la aplicación basada en la web, así que investigué un poco con Reflector. Descubrí que el culpable era la clase interna FileChangesMonitor .

Así que escribí un horrible y horrible truco de reflexión para resolver el problema. Pensé que lo publicaría aquí como una solución potencial para cualquier otra persona que tenga el mismo problema. Solo necesita llamar a HttpInternals.StopFileMonitoring () para desactivar el apagado en los cambios de archivo / carpeta.

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);
    }
}

Answer 4

Una solución sería agregar el siguiente elemento a la sección web.config:

<httpRuntime
    waitChangeNotification="315360000"
    maxWaitChangeNotification="315360000"
/>

Answer 5

Como mencionó jfburdet, la solución es utilizar 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