Develop Reference

Is it possible to extend IServiceProvider during runtime

TLDR: Is it possible to modify the IServiceProvider after the Startup has ran?
I am running dll's (which implement a interface of me) during run-time. Therefore there's a file listener background job, which waits till the plugin-dll is dropped. Now I want to register classes of this dll to the dependency-injection system. Therefore I added IServiceCollection as a Singleton to the DI inside ConfigureServices to use inside another method.
In therefore I created a test-project and just tried to modify the ServiceCollection in the controller, because it was easier than stripping the background job down.
services.AddSingleton<IServiceCollection>(services);
So I added IServiceCollection to my controller to check if I can add a class to the DI after the Startup class has ran.
[Route("api/v1/test")]
public class TestController : Microsoft.AspNetCore.Mvc.Controller
{
private readonly IServiceCollection _services;
public TestController(IServiceCollection services)
{
_services = services;
var myInterface = HttpContext.RequestServices.GetService<IMyInterface>();
if (myInterface == null)
{
//check if dll exist and load it
//....
var implementation = new ForeignClassFromExternalDll();
_services.AddSingleton<IMyInterface>(implementation);
}
}
[HttpGet]
public IActionResult Test()
{
var myInterface = HttpContext.RequestServices.GetService<IMyInterface>();
return Json(myInterface.DoSomething());
}
}
public interface IMyInterface { /* ... */ }
public class ForeignClassFromExternalDll : IMyInterface { /* ... */ }
The Service was successfully added to the IServiceCollection, but the change is not persisted yet to HttpContext.RequestServices even after multiple calls the service count increases each time but I don't get the reference by the IServiceProvider.
Now my question is: Is that possible to achieve and yes how. Or should I rather not do that?

Is it possible to modify the IServiceProvider after the Startup has ran?
Short answer: No.
Once IServiceCollection.BuildServiceProvider() has been invoked, any changes to the collection has no effect on the built provider.
Use a factory delegate to defer the loading of the external implementation but this has to be done at start up like the rest of registration.
services.AddSingleton<IMyInterface>(_ => {
//check if dll exist and load it
//....
var implementation = new ForeignClassFromExternalDll();
return implementation;
});
You can now explicitly inject your interface into the controller constructor
private readonly IMyInterface myInterface;
public MyController(IMyInterface myInterface) {
this.myInterface = myInterface;
}
[HttpGet]
public IActionResult MyAction() {
return Json(myInterface.DoSomething());
}
and the load dll logic will be invoked when that interface is being resolved as the controller is resolved.

ASP.NET core call async init on singleton service

I have a service that asynchronously reads some content from a file in a method called InitAsync
public class MyService : IService {
private readonly IDependency injectedDependency;
public MyService(IDependency injectedDependency) {
this.injectedDependency = injectedDependency;
}
public async Task InitAsync() {
// async loading from file.
}
}
Now this service is injected into my controller.
public class MyController : Controller {
private readonly IService service;
public MyController(IService service) {
this.service = service;
}
}
Now I want a singleton instance of MyService. And I want to call InitAsync in startup.
public class Startup {
public void ConfigureServices(IServiceCollection services) {
......
services.AddSingleton<IService, MyService>();
var serviceProvider = services.BuildServiceProvider();
// perform async init.
serviceProvider.GetRequiredService<IService>().InitAsync();
}
}
What is happening is at the time of startup, an instance of MyService is created and InitAsync() is called on it. Then when I called the controller class, another instance of MyService is created which is then reused for consequent calls.
What I need is to initialize only 1 instance, called InitAsync() on it in startup and have it be reused by controllers as well.

What is happening is at the time of startup, an instance of MyService is created and InitAsync() is called on it. Then when I called the controller class, another instance of MyService is created which is then reused for consequent calls.
When you call BuildServiceProvider(), you create a separate instance of IServiceProvider, which creates its own singleton instance of IService. The IServiceProvider that gets used when resolving the IService that's provided for MyController is different to the one you created yourself and so the IService itself is also different (and uninitialised).
What I need is to initialize only 1 instance, called InitAsync() on it in startup and have it be reused by controllers as well.
Rather than attempting to resolve and initialise IService inside of Startup.ConfigureServices, you can do so in Program.Main. This allows for two things:
Using the same instance of IService for initialisation and later use.
awaiting the call to InitAsync, which is currently fire-and-forget in the approach you've shown.
Here's an example of how Program.Main might look:
public static async Task Main(string[] args)
{
var webHost = CreateWebHostBuilder(args).Build();
await webHost.Services.GetRequiredService<IService>().InitAsync();
webHost.Run();
// await webHost.RunAsync();
}
This uses async Main to enable use of await, builds the IWebHost and uses its IServiceProvider to resolve and initialise IService. The code also shows how you can use await with RunAsync if you prefer, now that the method is async.

You can use simply way to do that with nuget HostInitActions
public void ConfigureServices(IServiceCollection services)
{
services.AddSingleton<IService, MyService>();
services.AddAsyncServiceInitialization()
.AddInitAction<IService>(async (service) =>
{
await service.InitAsync();
});
}
This nugget ensures that your initialization action will be performed asynchronously before the application starts.
Another advantage of this approach is that this initialization action can be defined from any place where services are installed into the IServiceCollection (For example, in an extension method in another project that installs internal implementations of public interfaces). This means that the ASP.NET Core project does not need to know what service and how it should be initialized, and it will still be done.

"Unable to resolve service for type" error when injecting IHostedService in another IHostedService

I am trying to inject an instance of IHostedService into another IHostedService but I always get the above error when Run() is called in my Program.cs.
Basically, I have two services:
public class CacheService : HostedService
{
public CacheService()
{
}
/...
}
public class ClientService : HostedService
{
private CacheService _cacheService;
public ClientService(CacheService cacheService)
{
_cacheService = cacheService;
}
/...
}
HostedService implements IHostedService:
public abstract class HostedService : IHostedService
{
// Example untested base class code kindly provided by David Fowler: https://gist.github.com/davidfowl/a7dd5064d9dcf35b6eae1a7953d615e3
private Task _executingTask;
private CancellationTokenSource _cts;
public Task StartAsync(CancellationToken cancellationToken)
{
// Create a linked token so we can trigger cancellation outside of this token's cancellation
_cts = CancellationTokenSource.CreateLinkedTokenSource(cancellationToken);
// Store the task we're executing
_executingTask = ExecuteAsync(_cts.Token);
// If the task is completed then return it, otherwise it's running
return _executingTask.IsCompleted ? _executingTask : Task.CompletedTask;
}
public async Task StopAsync(CancellationToken cancellationToken)
{
// Stop called without start
if (_executingTask == null)
{
return;
}
// Signal cancellation to the executing method
_cts.Cancel();
// Wait until the task completes or the stop token triggers
await Task.WhenAny(_executingTask, Task.Delay(-1, cancellationToken));
// Throw if cancellation triggered
cancellationToken.ThrowIfCancellationRequested();
}
// Derived classes should override this and execute a long running method until
// cancellation is requested
protected abstract Task ExecuteAsync(CancellationToken cancellationToken);
}
This is how I inject these services in my Startup.cs class:
private void AddRequiredServices(IServiceCollection services)
{
services.AddSingleton<IHostedService, CacheService>();
services.AddSingleton<IHostedService, ClientService>();
}
However, every time I run the application, I get an error that CacheService can't be resolved for service ClientService. Am I doing something wrong here or is this not supported?
EDIT: Here is a repository that you can clone which reproduces my issue.

As you are not injecting the IHostedService interface in your classes you should register the ClientService and CacheService directly to the service collection, instead of using the interface e.g.
private void AddRequiredServices(IServiceCollection services)
{
services.AddSingleton<CacheService>();
services.AddSingleton<ClientService>();
}
The Dependency Injector (DI) will be able to resolve the correct service and inject it into your constructor.
When you add a service with an interface, the DI will look for references to the interface in constructors and not the class, which is why it fails in your example to inject the correct instance.

#Simply Ged, your solution worked for me but it does not make sense to me. I am trying to achieve the same thing in my current project and were struggling since yesterday. Glad I found your post.
This post will help.
Injecting SimpleInjector components into IHostedService with ASP.NET Core 2.0

Why does Scoped service resolve as two different instances for same request?

I have a simple service that contains a List<Foo>. In Startup.cs, I am using the services.addScoped<Foo, Foo>() method.
I am inject the service instance in two different places (controller and middleware), and for a single request, I would expect to get the same instance. However, this does not appear to be happening.
Even though I am adding a Foo to the List in the Controller Action, the Foo list in the Middleware is always empty. Why is this?
I have tried changing the service registration to a singleton, using AddSingleton() and it works as expected. However, this has to be scoped to the current request. Any help or ideas are greatly appreciated!
FooService.cs
public class FooService
{
public List<Foo> Foos = new List<Foo>();
}
Startup.cs
...
public void ConfigureServices(IServiceCollection services)
{
...
services.AddScoped<FooService, FooService>();
}
[Below are the two places where I am injecting the service, resulting in two different instances]
MyController.cs
public class MyController : Controller
{
public MyController(FooService fooService)
{
this.fooService = fooService;
}
[HttpPost]
public void TestAddFoo()
{
//add foo to List
this.fooService.Foos.Add(new Foo());
}
}
FooMiddleware.cs
public AppMessageMiddleware(RequestDelegate next, IServiceProvider serviceProvider)
{
this.next = next;
this.serviceProvider = serviceProvider;
}
public async Task Invoke(HttpContext context)
{
context.Response.OnStarting(() =>
{
var fooService = this.serviceProvider.GetService(typeof(FooService)) as FooService;
var fooCount = fooService.Foos.Count; // always equals zero
return Task.CompletedTask;
});
await this.next(context);
}

That's because when you inject IServiceProvider into your middleware - that's "global" provider, not request-scoped. There is no request when your middleware constructor is invoked (middleware is created once at startup), so it cannot be request-scoped container.
When request starts, new DI scope is created, and IServiceProvider related to this scope is used to resolve services, including injection of services into your controllers. So your controller resolves FooService from request scope (because injected to constructor), but your middleware resolves it from "parent" service provider (root scope), so it's different. One way to fix this is to use HttpContext.RequestServices:
public async Task Invoke(HttpContext context)
{
context.Response.OnStarting(() =>
{
var fooService = context.RequestServices.GetService(typeof(FooService)) as FooService;
var fooCount = fooService.Foos.Count; // always equals zero
return Task.CompletedTask;
});
await this.next(context);
}
But even better way is to inject it into Invoke method itself, then it will be request scoped:
public async Task Invoke(HttpContext context, FooService fooService)
{
context.Response.OnStarting(() =>
{
var fooCount = fooService.Foos.Count; // always equals zero
return Task.CompletedTask;
});
await this.next(context);
}

First of all you shouldn't be using GetService, use the proper DI system that is in place by passing it into the Invoke method as a parameter.
Secondly, the reason you are getting a different object is because the constructor of the middleware is called outside of the scope of any request, during the app initialisation phase. So the container used there is the global provider. See here for a good discussion.
public class AppMessageMiddleware
{
private readonly RequestDelegate _next;
public AppMessageMiddleware(RequestDelegate next, IServiceProvider serviceProvider)
{
_next = next;
}
//Note the new parameter here: vvvvvvvvvvvvvvvvvvvvv
public async Task Invoke(HttpContext context, FooService fooService)
{
context.Response.OnStarting(() =>
{
var fooCount = fooService.Foos.Count;
return Task.CompletedTask;
});
await _next(context);
}
}

ASP.NET Core initialize singleton after configuring DI

So let's say I have a singleton class instance that I register in the DI like this:
services.AddSingleton<IFoo, Foo>();
And let's say the Foo class has a number of other dependencies (mostly repository classes that allow it to load data).
With my current understanding, the Foo instance is not created until it's first used (asked). Is there a way to initialize this class other than the constructor? Like right after ConfigureServices() completes? Or should the initialization code (loading data from db) be done in Foo's constructor?
(It would be nice if this class could load its data before the first use to speed up first time access)

Do it yourself during startup.
var foo = new Foo();
services.AddSingleton<IFoo>(foo);
Or "warm it up"
public void Configure(IApplicationBuilder app)
{
app.ApplicationServices.GetService<IFoo>();
}
or alternatively
public void Configure(IApplicationBuilder app, IFoo foo)
{
...
}
But this feels just dirty and is more a problem with your design, if you do something that you shouldn't in the constructor. Class instantiation has to be fast and if you do long-running operations within it, you break against a bunch of best practices and need to refactor your code base rather than looking for ways to hack around it

I got the same problem and I find Andrew Lock blog:
https://andrewlock.net/running-async-tasks-on-app-startup-in-asp-net-core-3/
He explains how to do this with asp .net core 3, but he also refers to his pages on how to to this with previous version.

Lately I've been creating it as an IHostedService if it needs initialization, because to me it seems more logical to let the initialization be handled by the service itself rather than outside of it.
You can even use a BackgroundService instead of IHostedService as it's pretty similar and it only needs the implementation of ExecuteAsync
Here's the documentation for them
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/host/hosted-services
An example of how to add the service so you can inject it directly:
services
.AddHostedService<MyService>()
.AddSingleton<MyService>(x => x
.GetServices<IHostedService>()
.OfType<MyService>()
.First());
Example of a simple service:
public class MyService : IHostedService
{
// This function will be called automatically when the host `starts`
public async Task StartAsync(CancellationToken cancellationToken)
{
// Do initialization logic
}
// This function will be called automatically when the host `stops`
public Task StopAsync(CancellationToken cancellationToken)
{
// Do cleanup if needed
return Task.CompletedTask;
}
}
Some extension methods I created later on because i needed to use the same pattern again
public static class HostedServiceExtensions
{
public static IServiceCollection AddHostedServiceAsService<T>(this IServiceCollection services) where T : class, IHostedService
=> services.AddHostedService<T>().AddSingleton(x => x.GetServices<IHostedService>().OfType<T>().First());
public static IServiceCollection AddHostedServiceAsService<T>(this IServiceCollection services, Func<IServiceProvider, T> factory) where T : class, IHostedService
=> services.AddHostedService(factory).AddSingleton(x => x.GetServices<IHostedService>().OfType<T>().First());
}
Used like
services.AddHostedServiceAsService<MyService>();
// Or like this if you need a factory
services.AddHostedServiceAsService<MyService>(x => new MyService());

Adding detail to Jérôme FLAMEN's answer, as it provided the key I required to calling an async Initialization task to a singleton:
Create a class that implements IHostedService:
public class PostStartup : IHostedService
{
private readonly YourSingleton yourSingleton;
public PostStartup(YourSingleton _yourSingleton)
{
yourSingleton = _yourSingleton;
}
// you may wish to make use of the cancellationToken
public async Task StartAsync(CancellationToken cancellationToken)
{
await yourSingleton.Initialize();
}
// implement as you see fit
public Task StopAsync(CancellationToken cancellationToken) => Task.CompletedTask;
}
Then, in your ConfigureServices, add a HostedService reference:
services.AddHostedService<PostStartup>();
From link.

I made some manager and I need to subscribe to events of the other services.
I didn't like doing this in the
webBuilder.Configure (applicationBuilder => ...
I think it should be in the section
webBuilder.ConfigureServices ((context, services) => ...
So, here is my answer (test on net.core 3):
public static IHostBuilder CreateHostBuilder (string [] args) =>
Host.CreateDefaultBuilder (args)
.ConfigureWebHostDefaults (webBuilder =>
{
...
services.AddSingleton<ISomeSingletonService,SomeSingletonService>();
var buildServiceProvider = services.BuildServiceProvider();
var someSingletonService = buildServiceProvider.GetRequiredService <ISomeSingletonService>();
...
});