Native / canonical Fire-and-forget approach in ASP.NET Core world

Question

Performing some encoding with the associated webcams, I found that it is currently unclear how to properly handle lengthy background processes or tasks performed using the Fire-and-Forget semantics (this is still true for ASP.NET Core 2.0 ) since there may be some pitfalls with a DI scale, application restart, etc.

So, it would be nice to get some wise ideas on how such things should be implemented in the .NET Core world without fantasy, like Hangfire

Answer 1

It might be worth checking out this MSDN Developer Blog on the IHostedService and BackgroundService class:

• Implementing background tasks in the .NET Framework 2.x webapps or microservices using IHostedService and the BackgroundService class

Summary:

The IHostedService interface provides a convenient way to run background tasks in an ASP.NET Core web application (in .NET Core 2.0) or in any process / host (starting with .NET Core 2.1 using IHost ). this Main advantage is the opportunity that you get with a graceful cancellation to clear the code of your background tasks when the host itself shuts down.

Answer 2

I will research this for several days. I have a similar question:

Asp.Net Core 2.0: An Easy Way To Perform Longer Tasks And Run Reports

I found an approach that uses QueueBackgroundWorkItem , but this is not available in Asp.Net Core.

The only thing I found consistent in people's answers is that fire-and-forget is what needs to be done outside of IIS. On a Windows service or something like Azure Web Jobs .

The only thing that just eliminates the need for a distributed architecture is Hangfire , but this is not recommended for critical operations.

Answer 3

I assume you are aware of two posts from @ScottHanselmann and @StephenCleary , where you can find mentions of Hangfire and similar libraries. However, these messages are a bit outdated, and they do not provide a solution for .Net Core.

As far as I can see, the proposed fire and swell script method in ASP.NET Core is to use IApplicationLifetime instead of QueueBackgroundWorkItem and IRegisteredObject . You can find a similar question here , and I suggest you carefully study the answers to it.

An example :

The idea (and I'm still not quite sure if it is pretty bad, so be careful!) Is to register a singleton that generates and oversees new tasks. Inside this singleton, we can also register a "stopped event" in order to wait for more running tasks.