This question is with regard to ASP.NET Core 2.2 applications running on IIS, specifically when registering instances of IHostedService with the DI container.
Every article I read about IHostedService.StopAsync() just talks about StopAsync() being called when the host "shuts down", but I want to know what happens when IIS recycles.
My question(s):
1. Is StopAsync() called when the IIS recycles?
2. Is the answer the same regardless of using InProcess hosting or OutOfProcess hosting? (ASP.NET Core supports InProcess as of version 2.2)
Is StopAsync() called when the IIS recycles?
Yes
Reference Implement background tasks in microservices with IHostedService and the BackgroundService class
Deployment considerations and takeaways
It is important to note that the way you deploy your ASP.NET Core
WebHost or .NET Core Host might impact the final solution. For
instance, if you deploy your WebHost on IIS or a regular Azure App
Service, your host can be shut down because of app pool recycles.
.....
note: emphasis mine
which by extension would stop any IHostedService,
Related
I need to host my Asp.NET Core gRPC Service on IIS so that I can make it publicly available for others in my team so can you please provide a proper document or steps for hosting my gRPC service on IIS.
Hosting .net core application in IIS is not yet supported. For more details please go through link
This document states that ASP.NET Core gRPC can be hosted on IIS, but it carries extra requirements.
IIS requires .NET 5 and Windows 10 Build 20300.1000 or later.
HTTP.sys requires .NET 5 and Windows 10 Build 19529 or later.
So please check if it meets the requirements before trying to publish it on IIS:
Host ASP.NET Core on Windows with IIS.
I am looking for the options to host existing ASP.NET Framework (not .NET Core, and not ASP.NET Core) applications in ServiceFabric hosted on-premise.
We host such legacy applications in IIS, as is the common practice I believe, and we are considering migrating them to an on-prem ServiceFabric cluster without (or at least, as little as possible) modifications.
I see that Visual Studio 2017 SF project templates do not have the "old ASP.NET", which makes me think that using old ASP.NET isn't preferred, if supported at all. I can understand that.
I understand that it is possible to deploy the application in a container with IIS, e.g. with Windows IIS.
Are there other possibilities?
I've been doing self-hosted ASP.Net WebAPI on Service Fabric for three years already. They did remove the .NET Framework WebAPI template when you create a Service Fabric App, but yes, you can still run a Self-hosted .Net Framework API on Service Fabric.
I still have my old code before so I pretty much do same thing over and over. This tutorial would help a lot. it's the basics of doing a self-hosted WebAPI, hosting it on HTTPS is another thing after that.
I need to run long running background tasks in my asp.net core application.
I know of Azure Webjobs and other out of process techniques but I'd rather keep the solution simple and runs those tasks directly in the asp.net core process.
I use Kestrel and the application is hosted in IIS.
I understand that IIS will occasionally recycle the IIS process. Will it also recycle the asp.net core process?
Asp.Net Core < 2.2
Asp.net Core runs in a separate process dotnet.exe even when it is hosted in IIS. But it doesn't mean that it runs as an independent process. IIS still responsible for Asp.net core process (dotnet.exe) life cycle through the AspNetCoreModule.
So, answer is yes, IIS will also recycle the asp.net core process
Asp.Net Core >= 2.2
Asp.Net Core 2.2 has in-process hosting support on IIS in addition to out-of-process hosting model that was before. It seems it is just an optimization that allows to avoid the additional cost of reverse-proxying requests over to a separate dotnet process. IIS will recycle application pool with Asp.net Core application
I have do a experiment
use ' IApplicationLifetime applicationLifetime ' like aspnet Golbal.aspx
When the iis application recycle , the registerd 'ApplicationStopping'
be triggered.
SO i will belive the https://github.com/aspnet/KestrelHttpServer/issues/1040#issuecomment-267506588
Nope, It would not. IIS application pool only takes care of w3wp.exe process.
ASP.NET Core is hosted by Kestrel process, and IIS is just a reverse proxy in front of it.
ASP.NET Core out of the box supports hosting in IIS and self-hosting scenarios using the Kestrel and WebListener HTTP servers. Accordingly to web.config / project.json looks like IIS is used, but if so it is not clear for my "why" so, as now IIS is acting just as a reverse proxy and the application itself runs as a separate process using the Kestrel HTTP server.
So the main question is "what" and "why" is used by default, if deploy to Azure?
Yes, when you publish to Azure App Services, IIS is used to host your application. As you said, it acts as a reverse proxy to your application, which is running Kestrel HTTP server. But IIS does more than that - it also manages the application process through application pool, which includes or may include:
restarting the app when web.config changes
starting the app on the first HTTP request
running the app as a specified user
recycling the app pool (and effectively restarting the app) on certain conditions
starting multiple app processes
handle webdeploy (this is what happens when you hit "Publish" in Visual Studio
Does asp run in the IIS application pool for which the website is configured? Or is the application pool only for asp.NET applications.
How do those two relate to each other, what do i need to know to understand who's doing what and where are they doing it...
An ASP Classic application will run in the application pool to which it is assigned.
ASP.NET application also run in their assigned application, hence its possible that one or more ASP.NET applications and one or more ASP applications will run in the same pool and therefore share process(es).
In IIS6 there is little relationship between the two (ASP and ASP.NET applications) they simply do their thing side-by-side. They share the same virtual memory space so if one is a hog the other is affected. Additionally if one crashes the process all other apps that are in the pool (ASP and/or ASP.NET) are affected. They also share a common ISAPI filter stack which runs on a per-process basis.
In IIS7 with the integrated pipeline things become, well, more integrated. ASP classic relies on the .NET based pipeline to deliver requests to handle.