Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs

Dashboard
Notifications
Mark all as read
Q&A

How to create fire and forget tasks Q&A in ASP.NET Core with dependency injection support?

+2
−0

One of the legacy applications our team manages contained the following pattern (in the controller):

// initialization
private readonly IServiceScopeFactory _serviceScopeFactory;

public FooController(IServiceScopeFactory serviceScopeFactory)
{
    _serviceScopeFactory = serviceScopeFactory;
}
// IServiceScopeFactory was polluting the application services
public IActionResult Foo()
{
    Task.Run(() => _fooService.DoFoo(_serviceScopeFactory));
    return Ok();
}

The main purpose was to allow for fire-and-forget tasks because some of them could be quite long and the client should not wait for them to complete.

I guess that this was required to still benefit from DI since all application logic relies on it.

I have found this SO question dealing and this answer seems to do the trick, but votes = 0 suggests that was not found particularly useful (despite the 10K views).

Is there a quick way to allow for fire-and-forget tasks with DI support?

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

1 answer

+2
−0

The way I made this work is not very quick but might provide extra benefit in the future. I have added Hangfire support to the application and use its BackgroundJob enqueuing mechanism as follows:

Plugging Hangfire

using Hangfire;
using Hangfire.MemoryStorage;

public void ConfigureServices(IServiceCollection services)
{
    // other initialization here
    ConfigureHangfire(services);
}

private void ConfigureHangfire(IServiceCollection services)
{
     // this can be replaced with another type of storage
     // for actual persistence, but it is enough for this example
     services.AddHangfire(opt => opt.UseMemoryStorage());
			JobStorage.Current = new MemoryStorage();
     }
}

public void Configure(IApplicationBuilder app)
{
    // other configuration here

    StartHangFireJobs(app);
}

protected void StartHangFireJobs(IApplicationBuilder app)
{
    app.UseHangfireServer();
    // this is optional, but it provides a nice dashboard to see all job runs
    app.UseHangfireDashboard();
}

Actual usage

public IActionResult ExportPTBContracts()
{
    // virtually anything can be called here     
    // and the DI will work as expected
    BackgroundJob.Enqueue(() => _fooService.DoFoo());
    return Ok();
}

The main disadvantage is that a third-party library is used. However, it allows to easily check how the jobs actually ran (how frequent were called, how much it took, unhandled errors, etc).

More information is provided by Hangfire Docs.

Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

Works for me (1 comment)

Sign up to answer this question »