перезапуск asp net приложения
Управление жизненным циклом приложения
Жизненный цикл приложения и запроса
Данное руководство устарело. Актуальное руководство: Руководство по ASP.NET Core
Как правло, для решения большинства задач в ASP.NET MVC не требуется управление жизненным циклом приложения. Однако понимание работы приложения и обработки запроса дает нам дополнительные возможности по настройке веб-приложения.
Жизненный цикл приложения ASP.NET MVC начинается с запуска веб-приложения для обработки HTTP-запросов. И когда приложение завершает свою работу, завершается и его жизненный цикл. Ключевую роль в запуске приложения играет файл Global.asax. Он определяет глобальный класс приложения. Например, стандартное содержимое файла Global.asax может выглядеть следующим образом:
По умолчанию в классе приложения определяется только метод Application_Start, в котором производится конфигурационная настройка: регистрация маршрутов, фильтров и т.д.
Метод Application_End вызывается перед завершением работы приложения и, как правило, используется для освобождения связанных ресурсов, наподобие подключений к базам данных, но сейчас, как правило, освобождение ресурсов можно произвести в коде самого приложения, и поэтому в методе Application_End нет большой необходимости.
Жизненный цикл запроса предполагает вызов ряда событий в следующей последовательности:
BeginRequest : событие возникает, когда приложение получает новый запрос
AuthenticateRequest/PostAuthenticateRequest : событие AuthenticateRequest возникает при идентификации (аутентификации) пользователя, сделавшего запрос. А после его обработки срабатывает событие PostAuthenticateRequest
AuthorizeRequest/PostAuthorizeRequest : AuthorizeRequest возникает при авторизации запроса, после этого срабатывает событие PostAuthorizeRequest
ResolveRequestCache/PostResolveRequestCache : событие ResolveRequestCache возникает, когда приложение обращается к кэшу для получения данных. При получении данных их кэша затем срабатывает событие PostResolveRequestCache
MapRequestHandler/PostMapRequestHandler : MapRequestHandler срабатывает при определении обработчика запроса. После выбора обработчика срабатывает событие PostMapRequestHandler
AquireRequestState/PostAquireRequestState : событие AquireRequestState возникает при получении данных состояния, связанных с запросом (например, данные сессии). И после него срабатывает событие PostAquireRequestState
ReleaseRequestState/PostReleaseRequestState : событие ReleaseRequestState возникает, когда приложению больше не требуются данные, ассоциированные с запросом. И после освобождения этих данных просиходит событие PostReleaseRequestState
UpdateRequestCache : возникает при обновлении данных в кэше
EndRequest : возникает при завершении обработки запроса, когда данные для ответа уже готовы к отправке клиенту
PreSendRequestHeaders : возникает перед отправкой HTTP-заголовков браузеру клиента
PreSendRequestContent : возникает после отправки заголовков, но перед отправкой основного содержимого ответа
Схематично жизненный цикл приложения и запроса можно представить следующим образом:
При необходимости мы можем обработать эти события. Например, в файле Global.asax.
Для этого нам надо определить в классе MvcApplication методы, имеют следующее наименование: Application_[Название_события]. Например, изменим класс в Global.asax следующим образом:
После этого мы можем обратиться к этому свойству в приложении, например, в контроллере HomeController. Пусть в нем происходит вывод всех отработавших событий на страницу:
Состояние приложения
Состояние приложения позволяет сохранять глобальные объекты, доступ к которым может получать любой клиент. В основе состояния приложения лежит класс System.Web.HttpApplicationState, который доступен на всех веб-страницах через встроенный объект Application.
Состояние приложения похоже на состояние сеанса. Оно поддерживает объекты тех же типов, хранит информацию на сервере и использует синтаксис, основанный на словаре. Наиболее распространенным примером применения состояния приложения является глобальный счетчик, отслеживающий информацию о том, сколько» раз отдельная операция выполнялась всеми клиентами данного веб-приложения.
Например, можно было бы создать обработчик событий в файле global.asax, который отслеживал бы число созданных сеансов или количество поступивших в приложение запросов. Или же можно было бы применить подобную логику в обработчике событий Page.Load для отслеживания количества запросов данной страницы различными клиентами. Ниже показан код для реализации последнего варианта:
Опять-таки, элементы состояния приложения хранятся в виде объектов, поэтому при извлечении из коллекции они должны приводиться к соответствующему типу. Время жизни элементов состояния приложения никогда не истекает. Они существуют до тех пор, пока приложение или сервер не будет перезапущен, или до тех пор, пока не произойдет автоматическое обновление домена приложения (согласно установленным настройкам либо в результате обновления одной из страниц или компонентов в приложении).
Состояние приложения применяется редко, потому что, как правило, является неэффективным. В предыдущем примере счетчик вряд ли бы всегда отображал точное значение, особенно при насыщенном трафике. Например, в случае, если бы одну и ту же страницу одновременно запросили два пользователя, последовательность событий выглядела следующим образом:
Пользователь А извлекает текущее значение счетчика (432).
Пользователь Б извлекает текущее значение счетчика (432).
Пользователь А устанавливает значение счетчика в 433.
Пользователь Б устанавливает значение счетчика в 433.
Другими словами, один из этих запросов не учитывается, потому что два клиента получают доступ к счетчику одновременно. Во избежание этой проблемы, следует использовать методы Lock() и UnLock(), которые явно позволяют получать доступ к коллекции состояния Application только одному клиенту за раз:
В прошлом коллекция состояния Application использовалась для хранения констант уровня приложения, таких как строка подключения к базе данных. Теперь же, константы такого типа теперь могут сохраняться в файле web.config; такой подход более удобен, потому что позволяет легко изменять эти константы, не выискивая их в коде веб-страницы и не компилируя приложение заново.
Состояние приложения также может применяться для хранения часто используемой информации, создание которой отнимает много времени (такой как полный каталог товаров, который требует просмотра базы данных). Однако использование для хранения такой информации коллекции Application приводит к появлению различных проблем вроде того, как проверить, являются ли данные действительными, и каким образом их заменить в случае необходимости. Это также может негативно сказаться на производительности, если каталог продуктов является слишком большим. Похожий, но более удобный подход — сохранить часто используемую информацию в кэше ASP.NET. Во многих случаях эффективнее применять кэширование, чем состояние приложения.
Состояние приложения поставляется главным образом для обратной совместимости с классической версией ASP. В новых приложениях для глобальных данных лучше применять другие подходы, например, использовать базу данных вместе с объектом Cache.
Статические переменные приложения
Глобальные переменные приложения можно хранить еще одним способом — путем добавления в файл global.asax статических переменных экземпляра, которые после этого компилируются в специальный класс веб-приложения по имени HttpApplication и делаются доступными для всех входящих в его состав страниц.
Ниже показан пример объявления статического массива строк:
Главной деталью, которая позволяет такому подходу работать, является статическая природа переменных. Все дело в том, что для обслуживания множества запросов ASP.NET создает пул классов HttpApplication. Это значит, что каждый запрос может обслуживаться с помощью отдельного объекта HttpApplication, а у каждого объекта HttpApplication имеются собственные данные экземпляра. Однако существует только одна копия статических данных, которая используется для всех экземпляров (на одном и том же веб-сервере).
Еще одним требованием, которое обязательно должно выполняться для того, чтобы эта стратегия работала, является наличие возможности получать в коде доступ к статическим переменным экземпляра, которые были добавлены в специальный класс приложения. Чтобы сделать это возможным, необходимо указать имя, которое должно использоваться для этого класса. Для этого устанавливается значение свойства ClassName в директиве Application, которая находится в начале файла global.asax.
Ниже показан пример назначения классу приложения имени Global:
После этого в веб-страницах можно будет использовать такой код:
как перезапустить приложение asp.net помимо изменения web.config
Есть ли рекомендуемый способ отказов приложения asp.net, кроме прикосновения к web.config изнутри приложения? is HttpRuntime.UnloadAppDomain() ; предпочтительный способ сделать это? и если да, то где ты это делаешь? В разгрузке страницы или другого места в приложении?
7 ответов
Эта последовательность событий заставит ASP.NET выгружать приложение, пока в папке существует файл app_offline.htm.
В документации конкретно говорится, что UnloadAppDomain закроет приложение:
UnloadAppDomain позволяет программно завершать работу неиспользуемых приложений.
этот код работает для меня. просто позвоните, чтобы перезагрузить приложение.
Этот метод просто выгружает наше приложение. Если вы просто поместите этот метод в веб-кнопку ASP.NET, то все готово. Так когда же наше приложение будет перезагружено? На самом деле, если вы нажмете на кнопку, он сначала запустит наш метод и выгрузит приложение. Далее на веб-странице, на которой мы находимся в этот момент, также будет перезагрузка, потому что мы просто нажали кнопку, и веб-страница должна обновиться. После запуска нашего метода процесс обновления страницы также приведет к перезагрузке нашего приложения.
Вы также можете остановить и запустить пул приложений, связанный с приложением.
Вы можете сделать это, вызвав метод HttpRuntime.ShutdownAppDomain (вам потребуется использовать отражение, чтобы вызвать его, поскольку это частный статический метод)
Вы можете безопасно перезапустить веб-приложение, создав или переименовав папку во время выполнения в каталоге приложения. Очевидно, вам нужно дать пользователю, назначенному для запуска приложения, «изменить» права на веб-каталог или вложенный каталог в нем.
Я использовал следующий код, чтобы сделать это в моем случае. Измените его так, чтобы он работал в «доступном для записи» подкаталоге
Если вы не хотите останавливаться и запускать пул приложений, вы всегда можете перезапустить его.
Горячая перезагрузка позволяет вносить изменения в исходный код приложения во время его выполнения без необходимости приостанавливать его вручную или создавать точку останова. Теперь прямо во время работы приложения можно внести в код изменение из числа тех, что поддерживаются для горячей перезагрузки, нажать кнопку «Применить изменения кода» в новом интерфейсе Visual Studio — и изменение будет сразу же применено.
Мы стремились сделать горячую перезагрузку доступной независимо от того, как вы предпочитаете запускать свои приложения. Представленную сегодня версию можно использовать в отладчике Visual Studio, с которым она полностью интегрирована, а также через командную строку ( dotnet watch ). В следующих выпусках появятся и другие варианты.
Начало работы
Visual Studio
Использование горячей перезагрузки в Visual Studio при работе с отладчиком:
Скачайте и установите Visual Studio 2019 16.11 (предварительная версия 1).
Откройте проект поддерживаемого типа, например приложение WPF.
Запустите приложение с подключенным отладчиком клавишей F5 (удостоверьтесь, что параметр «Разрешить отладку машинного кода» в настройках/профиле запуска отладчика отключен).
Откройте файл с кодом на C#, который может многократно запускаться по действию из пользовательского интерфейса выполняемого приложения (код программной части кнопки, команда ViewModel и т. п.) или по таймеру через некий интервал. Внесите в код какое-нибудь изменение.
Примените изменения кода с помощью новой кнопки Применить изменения кода (ALT + F10) на панели инструментов Visual Studio (рядом с кнопкой Продолжить). Сохранять файлы при использовании Visual Studio не нужно — можно быстро внести в код изменение и двигаться дальше.
Если внесенное изменение поддерживается, обновленная логика будет применена к запущенному приложению, и вы увидите изменения в его работе при следующем выполнении обновленного кода (по действию или при выполнении активирующего условия, например по таймеру).
Интерфейс командной строки (CLI)
Использование горячей перезагрузки из командной строки при запуске приложения с помощью dotnet watch:
Добавьте свойство » hotReloadProfile «: » aspnetcore » в профиль запуска приложения ( launchSettings.json ).
Пример файла Properties/launchSettings.json :
Запустите проект с помощью команды dotnet watch и убедитесь, что в выводе указано, что горячая перезагрузка активирована.
Внесите в управляемый исходный код приложения поддерживаемое изменение и сохраните файл, чтобы применить это изменение.
Как и в Visual Studio, с этого момента начнет применяться новая логика: при следующем выполнении обновленного кода вы увидите изменения в работе приложения.
Этот же подход можно использовать с проектами Blazor WebAssembly: следует изменить профиль горячей перезагрузки blazorwasm и далее действовать, как описано выше. Можно попробовать его даже с Windows Forms и другими типами проектов на платформе CoreCLR: для этого вручную добавьте в папку Properties файл с именем launchSettings.json и тем же содержимым, что в предыдущем примере.
Примеры ниже позволяют составить представление о том, какие возможности мы планируем реализовать в будущих предварительных выпусках и окончательной версии:
Работа в Visual Studio без отладчика. В будущем выпуске Visual Studio 2022 мы планируем добавить поддержку горячей перезагрузки без отладчика. Это значит, что даже при запуске приложения сочетанием клавиш CTRL + F5 разработчики смогут вносить изменения в выполняемое приложение.
Таковы планы на данный момент. Они не окончательные: мы будем прислушиваться к отзывам пользователей и ориентироваться на график выпусков.
Поддерживаемые и неподдерживаемые изменения и языки
Нам важны ваши отзывы
Конечно, в этой ранней предварительной версии будут ошибки. Иногда при попытке применить изменение ничего не будет происходить, иногда возможно аварийное завершение приложения и т. п. Если вы столкнетесь с какими-либо проблемами, сообщите нам о них — это не займет много времени. Ваша поддержка поможет нам эффективно устранить критические проблемы и определить приоритеты для дальнейшей работы.
Материал подготовлен в рамках курса «C# Developer. Professional». Если вас интересует развитие в C# разработке с нуля до Pro, предлагаем узнать про специализацию.
Также приглашаем всех желающих на открытый урок «Управление конфигурациями микросервисов». На занятии обсудим один из подходов, используемых в реальных high-load проектах.
Перезапустить приложение ASP.NET Core после сбоя
Я новичок в ASP.NET Core и учебе. Просто хотите узнать, есть ли способ перезапустить мое приложение после сбоя приложений?
Или этот сценарий обрабатывается по-разному?
Не могли бы найти какую-либо документацию по этому вопросу, может ли кто-нибудь указать мне в правильном направлении?
Если вы размещаете приложение ASP.NET Core за полным веб-сервером, используемым в качестве обратного прокси-сервера как IIS, оно будет выполнено автоматически. IIS получит запрос и передаст его в ваше приложение, (re), приступив к его запуску, если это необходимо. Вы можете проверить эту замечательную статью: https://weblog.west-wind.com/posts/2016/Jun/06/Publishing-and-Running-ASPNET-Core-Applications-with-IIS
Напротив, если вы используете просто Kestrel (но это не подходит для производства на самом деле), Kestrel остановится, и это, ваше приложение исчезнет.
При размещении своего ASP.NET Core приложения ASP.NET Core в качестве Windows Service вы можете настроить его для автоматического перезапуска, если процесс обслуживания завершается.
В своем коде просто сделайте Environment.Exit(1) чтобы завершить процесс, а затем пусть среда хостинга перезапустит его.
Как это настраивается в других средах, которые я не знаю, но я полагаю, что большинство хостов должны иметь такую конфигурацию в некотором роде. IIS, вероятно, делает это allready.
Однако это применимо только к исключениям, которые не убивают ваш процесс. Исключения в потоке запросов обычно не приводят к краху вашего приложения, но вы можете вообще отказаться от него и перезапустить, возможно, если у вас есть состояние в памяти, которое может закончиться неопределенным и, возможно, опасным способом после исключения.