Как предотвратить перезапуск приложения ASP.NET при изменении web.config?

У меня есть время выполнения ASP.NET с помощью метода ApplicationHost.CreateApplicationHost. Когда я изменяю web.config во время работы приложения, я вижу много первого шанса ThreadAbortException. Это прямо перед тем, как мое приложение рушится. Я предполагаю, что это связано с тем, что среда выполнения обнаружила изменения в конфигурации и хочет перезапустить.

На самом деле это не поддерживаемый сценарий, поэтому я бы предпочел, чтобы просто отключить автоматическую перезагрузку.

Кто-нибудь знает, как это сделать?

Ответ 1

Насколько я знаю, нет способа отключить это поведение, изменения в webconfig заставляют приложение перезапускаться.

Обновление: на самом деле это возможно, существует ряд методов, хорошо документированных, поскольку объясняется в этом ответе *

Оригинальный ответ:

Существует аналогичный вопрос здесь только для других ссылок. Я нашел дополнительную информацию, которая может быть полезна.

Изменения конфигурации Причина a Перезагрузка домена приложения
Изменения в настройки конфигурации в Web.config файлы косвенно вызывают применение домен для перезагрузки. Это поведение происходит по дизайну. Вы можете по желанию используйте атрибут configSource для справочные внешние файлы конфигурации которые не вызывают перезагрузки, когда изменение сделан. Чтобы получить больше информации, см. configSource в Общие атрибуты Унаследовано элементами раздела.

От Эта статья MSDN

* Отказ от ответственности: я написал другой ответ и, как правило, не стал самонаблюдением, но считаю его достаточно релевантным для ссылки здесь, поскольку через 8 лет после этого сообщения это действительно совсем другое: решение очень просто щелкнув по интерфейсу IIS, и обходные пути существуют после ASP.NET 1.0.

Ответ 2

Я столкнулся с еще более серьезной проблемой в тех же строках - изменения в любом файле или подпапке в базовом каталоге AppDomain приводят к отключению среды хостинга. Это довольно большая проблема для нашего приложения, поскольку мы запускаем интерфейс WPF в том же AppDomain, и мы не можем его перезапустить, не будучи недопустимым для пользователя.

Я действительно хотел избежать необходимости запуска отдельного AppDomain для веб-части приложения, поэтому я кое-что сделал с Reflector. Я обнаружил, что виновником был внутренний класс FileChangesMonitor.

Итак, я написал ужасный ужасный взлом для решения проблемы. Я думал, что отправлю его здесь как потенциальное решение для всех, у кого есть такая же проблема. Вам просто нужно вызвать HttpInternals.StopFileMonitoring(), чтобы отключить выключение при изменении файла/папки.

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

Ответ 3

Собственно, первые два ответа неверны. Возможно, и довольно легко предотвратить эту рециркуляцию, и эта функция была доступна, по крайней мере, с IIS6.

Метод 1 (в системной системе)

Измените параметр DWORD для реестра HKLM\SOFTWARE\Wow6432Node\Microsoft\ASP.NET\FCNMode на значение 1, которое отключит все уведомления об изменении файла.

Не путайте местоположение: Wow6432Node в этом случае не влияет на биттичность вашего веб-приложения.

Метод 2 (.NET 4.5 +)

Если вы используете .NET 4.5, то теперь можно отключить это на уровне сайта, просто используйте следующие в web.config:

<httpRuntime fcnMode="Disabled"/> 

Метод 3 (IIS6 +)

Наконец, а также (по крайней мере) вокруг с IIS6 там параметр, называемый DisallowRotationOnConfigChange, как параметр только для пула приложений (по крайней мере, это то, что я думаю, что текст в MSDN пытается сказать, но я его не тестировал). Установите его на true, и изменения в конфигурации пула приложений не приведут к немедленной переработке.

Этот последний параметр также можно установить из дополнительных настроек пула приложений:

Disable Recycling for Configuration Change

Метод 4 (ASP.NET 1.0 и 1.1)

Для (старых) веб-сайтов с использованием ASP.NET 1.0 или 1.1 есть подтвержденная ошибка, которая может привести к быстрым и повторяющимся повторениям в файле изменения. Обходной путь в то время был похож на то, что MartinHN предлагалось в основном вопросе, а именно следующее в web.config:

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

Это не отключает рециркуляцию, но это происходит только после 5000 перекомпиляций. Является ли это число полезным, зависит от размера вашего приложения. Microsoft не ясно говорит, что такое перекомпиляция. Однако значение по умолчанию - 15.

В стороне: независимо от версии .NET или Windows, мы обнаруживаем, что когда приложение запускается из общего ресурса и используется в среде с балансировкой нагрузки, сайт постоянно перерабатывается. Единственный способ решить эту проблему - добавить параметр FNCMode в реестр (но теперь есть более мелкие варианты).

Ответ 4

Решение будет добавлять следующий элемент в раздел web.config:

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

Ответ 5

Как упоминалось jfburdet, решение должно использовать waitChangeNotification и maxWaitChangeNotification.

При этом вы должны знать, что они не работают на IIS 7, если ASP.NET запущен в смешанном режиме: http://forums.iis.net/t/1149344.aspx