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.
Related
I have a wcf service hosted at IIS and multiple clients are already calling it. Now we want to get rid of windows and move our web api to linux therefore we are going for asp.net core gRPC. Now my question is:
Do my clients need to make changes on their side when we shift towards asp.net core?
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,
I am trying to figure out how to manage all those running ASP.NET Core processes which are hosted in an IIS reverse proxy setup; being kicked-off out-of-process by the ASP.NET Core native IIS module.
I.e. for a given IIS end-point how to find out which out-of-process ASP.NET Core process is attached to the responsible W3WP.exe reverse proxy worker process.
I noticed three variations:
.NET Core Framework dependent ASP.NET Core deployments (FDD) use a dotnet.exe based process; where dotnet.exe executes the specified ASP.NET Core DLL;
Self-contained ASP.NET Core deployments (SCD) use an < applicationname >.exe based process;
Full framework ASP.NET Core deployments use an < applicationname >.exe scheme as well.
Are there IIS Management PowerShell cmdlets available and/or other means to probe all running ASP.NET Core native IIS module instances?
https://learn.microsoft.com/en-us/dotnet/core/deploying/
If I want to selfhost a asp.net web api application with Owin in a windows service, how can I integrate kind of a application pool recycling that IIS offers?
The answer is simple: you cannot. Application pool is an IIS feature that you can only enjoy by hosting on IIS.
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.