This project is read-only.

.Net Core 5

Nov 14, 2014 at 11:09 PM
Hello, are there any plans to make a .Net Core 5 compatible version of Simple Injector in the near future? Thanks.
Nov 15, 2014 at 7:52 AM
Simple Injector is currently compatible to Mono. Is there any reason for you to believe that it isn't compatible with .NET Core?
Nov 15, 2014 at 10:53 PM
Edited Nov 15, 2014 at 11:00 PM
Fair question...I was attempting to add a DI adapter for ASP.Net VNext: I noticed that I wasn't able to target the Core 5 framework. Honestly still learning about what can/can't be targeted to Core5 and there isn't much out there to go on.

BTW...if you have any advice on how to correctly implement this, it would be appreciated. I looks like SimpleInjector already implements IServiceProvider...but also looks like it's necessary to implement a fallback provider (based on what I see implemented for Ninject and Autofac).

Was also somewhat stumped on the best way to set up the IServiceScope. It looks like this would be best served by registering within an ExecutionContextScopeLifestyle. Essentially it's looking for the return of a scoped container....

Anyway...any help appreciated.
Nov 15, 2014 at 11:54 PM
Edited Nov 16, 2014 at 12:05 PM
Simple Injector indeed already implements IServiceProvider, but I don't know what the best scoping would be for ASP.NET. Since vNext is deep into async, my best bet is the ExecutionContextScopeLifestyle (for now). I image this to be something like:
private class SimpleInjectorServiceScopeFactory : IServiceScopeFactory{
    private readonly Container container;
    public SimpleInjectorServiceScopeFactory(Container container) {
        this.container = container;

    public IServiceScope CreateScope() {
        return new SimpleInjectorServiceScope(container, container.BeginExecutionContextScope());

private class SimpleInjectorServiceScope : IServiceScope {
    private readonly Container container;
    private readonly Scope scope;
    public SimpleInjectorServiceScope(Container container, Scope scope) {
        this.container = container;
        this.scope = scope;

    public IServiceProvider ServiceProvider {
        get { return this.container; }

    public void Dispose() {
For beginning and finishing a scope, I think this piece of infrastructure is fine, but to be honest, I think the attempt of Microsoft to add DI like this is a really really bad idea, as Mark Seemann explained clearly here. It's an implementation of the conforming container anti-pattern.

Instead, you can just register Simple Injector for your own classes as you would normally do, and if you need to replace any ASP.NET specific service, just replace that in their built-in container, but leave your container of choice out of the picture. There's no need to deeply integrate your DI container with ASP.NET.
Nov 16, 2014 at 2:26 AM
Perhaps I'm incorrect, but my impression was that in ASP.Net vNext, if you want your dependencies injected into MVC/WebAPI controllers, you have to set up DI in this way. And basically at that point it's going to use your IOC container for everything. I do understand Seemann's point, but I really see this as an advantage in some ways. It really irked me that in MVC 5 when using OWIN for authentication, you actually had to stuff dependencies into request context so that they could be shared between the framework and your own code (in this case sharing EF context). So at least everything that needs your custom dependencies is getting them from the same place.

Thanks a lot for the examples, I'll see how it works out.