Come impedire il riavvio di un'applicazione ASP.NET quando il web.config viene modificato?

Question

Sto ospitando il runtime ASP.NET tramite il metodo ApplicationHost.CreateApplicationHost . Quando modifico il web.config mentre l'applicazione è in esecuzione, vedo molte volte lanciate ThreadAbortException . Questo è giusto prima che la mia applicazione si blocchi. Suppongo che ciò avvenga perché il runtime ha rilevato modifiche alla configurazione e desidera riavviare.

Questo non è davvero uno scenario supportato per noi, quindi preferirei se potessi semplicemente disattivare il ricaricamento automatico.

Qualcuno sa come farlo?

Answer 1

Per quanto ne so non c'è modo di disabilitare questo comportamento, le modifiche al webconfig impongono il riavvio dell'applicazione.

Aggiornamento: in realtà è possibile, ci sono una serie di metodi, ben documentati, come spiegato in questa risposta *

Risposta originale:

C'è una domanda simile qui solo per altri riferimenti. Ho trovato informazioni aggiuntive che potrebbero essere utili.

  

Le modifiche alla configurazione causano un riavvio   del dominio dell'applicazione
  Cambia in   impostazioni di configurazione in Web.config   i file causano indirettamente l'applicazione   dominio da riavviare. Questo comportamento   si verifica in base alla progettazione. Puoi opzionalmente   utilizzare l'attributo configSource per   fare riferimento a file di configurazione esterni   che non causano un riavvio quando a   il cambiamento è fatto. Per maggiori informazioni,   vedi configSource in Attributi generali   Ereditato da Section Elements.

Da Questo articolo MSDN

* ^{Disclaimer: ho scritto l'altra risposta e normalmente non farei un auto-riferimento, ma lo trovo abbastanza rilevante da collegarmi qui da 8 anni dopo questo post, è molto diverso: una soluzione è molto semplice facendo clic sul front-end IIS, esistono soluzioni alternative da ASP.NET 1.0.}

Answer 2

In realtà, le prime due risposte sono errate. è possibile, e abbastanza semplice, impedire che questo riciclaggio si verifichi e questa funzione è disponibile almeno da IIS6.

Metodo 1 (a livello di sistema)

Modifica l'impostazione del registro DWORD per HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ ASP.NET \ FCNMode sul valore 1 , che disabilitare tutte le notifiche di modifica del file.

Non essere confuso dalla posizione: Wow6432Node , in questo caso, non ha alcuna influenza sul testimone della tua applicazione web.

Metodo 2 (.NET 4.5+)

Se si utilizza .NET 4.5, è ora possibile disabilitarlo su un per livello di sito , usa semplicemente quanto segue nel tuo web.config :

<httpRuntime fcnMode="Disabled"/> 

Metodo 3 (IIS6 +)

Infine, e anche (almeno) in giro da IIS6, esiste un'impostazione chiamata DisallowRotationOnConfigChange come impostazione solo per il pool di applicazioni (almeno questo è ciò che penso il testo su MSDN tenta di dire, ma non ho ancora testato esso). Impostalo su true e le modifiche alla configurazione del pool di applicazioni non comporteranno un riciclo immediato.

Quest'ultima impostazione può essere impostata anche da Impostazioni avanzate del pool di applicazioni:

Metodo 4 (ASP.NET 1.0 e 1.1)

Per i (vecchi) siti Web che utilizzano ASP.NET 1.0 o 1.1, è presente un bug confermato che può causare ricicli rapidi e ripetuti sulle modifiche ai file. La soluzione alternativa all'epoca era simile a ciò che MartinHN ha suggerito sotto la domanda principale, vale a dire qualcosa di simile al seguente nel tuo web.config :

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

Ciò non disabilita il riciclaggio, ma lo fa solo dopo che sono state eseguite le ricompilazioni 5000 . L'utilità di questo numero dipende dalle dimensioni dell'applicazione. Microsoft non dice chiaramente cosa sia realmente una ricompilazione . L'impostazione predefinita, tuttavia, è 15 .

A parte: indipendentemente dalla versione di .NET o Windows, scopriamo che quando l'applicazione viene eseguita da una condivisione e utilizzata in un ambiente bilanciato dal carico, il sito ricicla continuamente. L'unico modo per risolverlo è stato aggiungendo l'impostazione FNCMode al registro (ma ora ci sono opzioni più dettagliate).

Answer 3

Ho riscontrato un problema ancora più grande sulla stessa linea: le modifiche a qualsiasi file o sottocartella nella directory di base AppDomain causano l'arresto dell'hosting. Questo è un grosso problema per la nostra applicazione poiché stiamo eseguendo un'interfaccia utente WPF nella stessa AppDomain e non possiamo riavviarla senza essere distruttivi per l'utente.

Volevo davvero evitare di eseguire un AppDomain separato per la parte dell'applicazione basata sul web, quindi ho scavato con Reflector. Ho scoperto che il colpevole era la classe interna FileChangesMonitor .

Quindi ho scritto un orribile hack di riflessione orribile per risolvere il problema. Ho pensato di pubblicarlo qui come potenziale soluzione per chiunque avesse lo stesso problema. Devi solo chiamare HttpInternals.StopFileMonitoring () per disabilitare l'arresto delle modifiche ai file / cartelle.

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 soluzione aggiungerebbe il seguente elemento alla sezione web.config:

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

Answer 5

Come menzionato da jfburdet, la soluzione consiste nell'usare waitChangeNotification e maxWaitChangeNotification.

Detto questo, dovresti sapere che non funzionano su IIS 7 se ASP.NET viene eseguito in modalità mista: http://forums.iis.net/t/1149344.aspx