Он не только работает "всегда", но имеет несколько режимов работы. Можно деплоить приложение как модуль IIS, так и сделать его stand alone. Первый вариант в свою очередь разделяется на два: "классический" и "интегрированный".
1. Классический подразумевает что IIS загружает DLL модуль ISAPI который в свою очередь запускает NET-среду в отдельном потоке. Так что даже в этом случае ASP NET CORE (или более ранний ASP NET ) работает "всегда". (В отличие от просто ASP который был до NET). Не смотря на то, что на картинках в документации обработка начинается только с приходом запроса, там всё равно присутствует процесс и поток отвечающий за работу ASP NET. В нём запускается global.asax. Но этот процесс может быть в любое время перезапущен IIS, если хоть что то ему "не понравится" (включая, например что процесс был запущен слишком давно. Часть этих параметров доступна для изменения в пуле приложений IIS)
2. В интегрированном режиме примерно всё тоже самое, за тем исключением, что там NET-среда уже является частью пайплайна IIS и приложению доступна возможность обрабатывать больше событий. Т к теперь это часть IIS, то штатным завершением будет выгрузка домена приложения из памяти. Но т к это может быть не возможно по разным причинам, IIS всё равно может перезапустить процесс вместе со всем пулом приложений. В штатном режиме обычно этого не происходит. Однако тут нужно сделать ремарку:
Если под понятием "работает всегда" понимать запуск какой-то своей бэкграунд-задачи в отдельном потоке, то есть нюансы. Для старого ASP NET это описано в этом блоге
haacked.com/archive/2011/10/16/the-dangers-of-impl... Для ASP NET CORE Микросософт сделал усилие и расширил как саму возможность правильного запуска фоновых задач, так и документацию:
https://docs.microsoft.com/ru-ru/aspnet/core/funda...
И здесь нужно заметить, что никто не мешает просто запустить новый поток самостоятельно, но это не штатная работа и чревата всё теми же последствиями какие описаны в том блоге.
3. Режим stand alon более простой. Это отдельное консольное NET-приложение, в котором внутри работает HTTP-сервер Kestrel. Но в сравнении с IIS я бы назвал его "недосервер", т к у него мало того что нет большей части функций IIS, так ещё и хромает документация. Но всё равно, даже несмотря на это он во многом лучше IIS по причине своей простоты. Кроме того он является безальтернативным решением, если ваше приложение должно работать в docker-контейнере или на ОС отличной от Windows, где IIS не завезли пока. Т к это отдельное приложение, там можно запустить сколько угодно потоков и это не должно привести к описанным проблемам. Но всё равно лучше использовать штатные средства. Хотя бы в целях переносимости приложения между IIS и stand alone режимами.
