Comment empêcher une application ASP.NET de redémarrer lorsque le fichier web.config est modifié?

Question

J'héberge le runtime ASP.NET via la méthode ApplicationHost.CreateApplicationHost . Lorsque je modifie le web.config alors que l'application est en cours d'exécution, je vois beaucoup de ThreadAbortException de première chance levés. C'est juste avant que mon application tombe en panne. Je suppose que cela est dû au fait que le moteur d'exécution a détecté des modifications de la configuration et souhaite redémarrer.

Ce scénario n'est pas vraiment pris en charge pour nous, je préférerais donc simplement désactiver le rechargement automatique.

Quelqu'un sait-il comment faire cela?

Answer 1

Pour autant que je sache, il n'y a aucun moyen de désactiver ce comportement, des modifications apportées à la commande webconfig forcent le redémarrage de l'application.

Mise à jour: il est en fait possible, il existe un certain nombre de méthodes bien documentées, comme expliqué dans cette réponse *

Réponse originale:

Il existe une question similaire ici à titre d'information. J'ai trouvé des informations supplémentaires qui pourraient être utiles.

  

Des modifications de configuration entraînent un redémarrage   du domaine d'application
  Changements à   paramètres de configuration dans Web.config   les fichiers causent indirectement l'application   domaine à redémarrer. Ce comportement   se produit par la conception. Vous pouvez éventuellement   utilisez l'attribut configSource pour   référence des fichiers de configuration externes   qui ne provoque pas un redémarrage quand un   le changement est fait. Pour plus d'informations,   voir configSource dans Attributs généraux   Hérité par les éléments de la section.

De Cet article MSDN

* ^{Clause de non-responsabilité: j’ai écrit l’autre réponse et je n’aurais normalement pas voulu me faire référence, mais j’ai trouvé assez pertinent de faire un lien ici, car 8 ans après cet article, c’est vraiment très différent: une solution est très simple en cliquant sur l'interface frontale IIS et des solutions de contournement existent depuis ASP.NET 1.0.}

Answer 2

En fait, les deux premières réponses sont incorrectes. Il est possible et assez facile d'empêcher ce recyclage, et cette fonctionnalité est disponible depuis au moins IIS6.

Méthode 1 (à l'échelle du système)

Remplacez le paramètre de registre DWORD pour HKLM \ SOFTWARE \ Wow6432Node \ Microsoft \ ASP.NET \ FCNMode par la valeur 1 , qui sera désactiver toutes les notifications de changement de fichier.

Ne vous laissez pas berner par l'emplacement: Wow6432Node n'a, dans ce cas, aucune influence sur le nombre de bits de votre application Web.

Méthode 2 (.NET 4.5 +)

Si vous utilisez .NET 4.5, il est maintenant possible de le désactiver sur un niveau par site , utilisez simplement les éléments suivants dans votre web.config :

<httpRuntime fcnMode="Disabled"/> 

Méthode 3 (IIS6 +)

Enfin et également (au moins) depuis IIS6, il existe un paramètre appelé DisallowRotationOnConfigChange comme paramètre uniquement pour le pool d'applications (du moins c'est ce que le texte sur MSDN essaie de dire, mais je n'ai pas testé il). Définissez-la sur true et les modifications apportées à la configuration du pool d'applications n'entraîneront pas de recyclage immédiat.

Ce dernier paramètre peut également être défini à partir des paramètres avancés du pool d'applications:

Méthode 4 (ASP.NET 1.0 et 1.1)

Pour les (anciens) sites Web utilisant ASP.NET 1.0 ou 1.1, un bogue a été confirmé. pouvant entraîner des recycles rapides et répétés lors des modifications de fichiers. La solution de contournement à l'époque était similaire à celle suggérée par MartinHN sous la question principale, à savoir quelque chose comme ce qui suit dans votre web.config :

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

Cela ne désactive pas le recyclage, mais seulement après que les 5000 recompilations ont eu lieu. L'utilité de ce nombre dépend de la taille de votre application. Microsoft ne dit pas clairement en quoi consiste une recompilation . Cependant, la valeur par défaut est 15 .

En passant: quelle que soit la version de .NET ou Windows, nous constatons que, lorsque l'application est exécutée à partir d'un partage et utilisée dans un environnement à charge équilibrée, le site est recyclé en permanence. La seule façon de le résoudre consistait à ajouter ce paramètre FNCMode au registre (mais il existe maintenant des options plus détaillées).

Answer 3

J’ai rencontré un problème encore plus grave allant dans le même sens: les modifications apportées à un fichier ou un sous-dossier dans le répertoire de base AppDomain provoquaient l’arrêt de l’environnement d’hébergement. C’est un gros problème pour notre application, car nous exécutons une interface utilisateur WPF dans le même AppDomain et nous ne pouvons pas le redémarrer sans être gênants pour l’utilisateur.

Je voulais vraiment éviter de devoir exécuter un AppDomain séparé pour la partie Web de l'application. J'ai donc creusé avec Reflector. J'ai trouvé que le coupable était la classe interne FileChangesMonitor .

Alors j’ai écrit un horrible horrible réflexe pour résoudre le problème. Je pensais que je le posterais ici comme solution potentielle pour quiconque ayant le même problème. Vous devez simplement appeler HttpInternals.StopFileMonitoring () pour désactiver l’arrêt des modifications de fichiers / dossiers.

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

Une solution serait d'ajouter l'élément suivant à la section web.config:

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

Answer 5

Comme mentionné par jfburdet, la solution consiste à utiliser waitChangeNotification et maxWaitChangeNotification.

Cela étant dit, vous devez savoir qu'ils ne fonctionnent pas sur IIS 7 si ASP.NET est exécuté en mode mixte: http://forums.iis.net/t/1149344.aspx