Support for Microsoft's new DependencyInjection abstractions.

[pauldotknopf]

https://github.com/aspnet/DependencyInjection

[dotnetjunkie]

What are you expecting? How should we support the new Microsoft's abstractions? If you are expecting to see an adapter for the new DI library, that won't happen, as explained here.

[pauldotknopf]

Check out StructureMap.dnx.

It implements Register methods and Resolve methods. The core libraries of .NET (EntityFramework, etc) support this abstraction. If you provide the implementation, users can get going with ASP.NET a lot quicker. SimpleInjector is my go-to DI tool, so, I'd love to see it supported.

[pauldotknopf]

@dotnetjunkie Shit. I'll take a look at that issue. Is there a show blocker reason, or just an opinion?

[dotnetjunkie]

We are going to support a dotnetcore/DNX compatible version of the Simple Injector core library, but we advice against using any adapter over the built-in system and keep the application's configuration separate from the framework's configuration. For that reason (among others) we will not create an official adapter project on top of the DI abstractions.

[pauldotknopf]

I like the story of library developers using the abstraction, and consumers/implementations can use any DI they want.

[dotnetjunkie]

@theonlylawislove: Read that issue. That issue will learn you two things:

1. An adapter over the DI system is useless, superfluous and just in the way, and
2. Due to the deliberate design of Simple Injector, it is highly incompatible with the DI abstractions (but note that this more or less holds for all existing containers).

[pauldotknopf]

Well, as just another random voice on the internet, I disagree.

Imagine a large project, such as MvcSiteMap. It contains like 50 services/implementations, but they are ALL simple interface>implementation mappings. I'd love a world where I can add this:

{
  "dependencies": {
    "MvcSitemap": ""
  }
}

...and be able to immediately use the services.

So, number 1 of your arguement, I disagree with, when you take into account that projects will typically have many dependencies. Also, if we move the responsibility of registering the services of a library to the library itself, then I wouldn't have to manage my mappings my self. If I upgrade to a newer version of a library that contains 5 more interface/implementations, I won't have to change any of my code.

As for number 2, I can't comment on it. Your an incredibly smart dude, and I trust your opinion here, but I really hope there is an easy way to modify SimpleInjector to make it more seamless/compatible.

Going forward with .NET 5, you will see libraries support this abstraction more and more. It would be a disservice to your project to force people that are considering to use your library to manually wire up every service from every dependency in their project.

I'd also like to add that the current SimpleInjector web scope stuff depends on an HttpModule to clean of dependencies here.

So, as it stands, there is no way to have a web-scoped controller in ASP.NET 5, since there are no more HttpModules. Using ASP.NET's abstraction, if you implement a IScopeProvider (or something named like that), it will manage the web request begin/end for you. Otherwise, SimpleInjector will have to create it's own OWIN middleware to wrap each request up in it's own IDisposable interface.

Update: I see you have the OWIN stuff supported here, but it doesn't support that RegisterPerWebRequest, since it uses a different scope. Is this correct?

[dotnetjunkie]

if we move the responsibility of registering the services of a library to the library itself
It would be a disservice to your project to force people that are considering to use your library to manually wire up every service from every dependency in their project.

You are forgetting that your application code should not have any hard dependencies on external libraries, as the Dependency Inversion Principles prescribes. Whether or not those libraries expose interfaces or just concrete classes doesn't matter. Those abstractions are not tailored to suit our applications’ special needs, so we want to hide those library classes behind application-specific abstractions and have adapter implementations that translate application-specific calls to calls that fit the external tool.

When you do that, that external library can use whatever method it likes to manage its dependencies internally. It can have an internal structure and provide you with facades, or it can hook into the new DI framework if it wishes to do so. In case a facade is used, your adapter will have to call the facade. If that library uses the new DI stuff, your adapter can just resolve such class from the DI infrastructure.

I really hope there is an easy way to modify SimpleInjector to make it more seamless/compatible.

As you might have read here, Simple Injector is designed in a very deliberate way to provide its users with the best possible experience. One of the unique qualities is how its API can prevent problems and on top of that, the Diagnostic system can detect problems at an early stage. Modifying Simple Injector to be more compatible with the new DI abstractions will make Simple Injector loose some of its unique abilities, and this is not something I take lightly.

By no means I would force people do everything by hand. You can happily let those libraries use the built-in DI abstractions, but by all means, do keep your application and its configuration clean and verifiable; keep your application configuration separate from anything else. This is an advice that I would give even if Simple Injector was compatible with the new DI stuff.

So, as it stands, there is no way to have a web-scoped controller in ASP.NET 5

Simple Injector's WebRequestLifestyle is designed for Web Forms and MVC and depends directly on HttpContext. You are right that it is not compatible with ASP.NET 5. For a long time however, Simple Injector contains an ExecutionContextScopeLifestyle that allows scoping across asynchronous method calls. This lifestyle is used by developers when integrating Simple Injector with Web API and OWIN today.

So as you can read in the referenced issue, scoping in ASP.NET 5 can be applied by making registrations with the ExecutionContextScopeLifestyle. The only difference with the WebRequestLifestyle is that it implicitly begins a scope for you. With ASP.NET 5 you will have to this manually (for now):

app.Use(async (context, next) => {
    using (this.container.BeginExecutionContextScope()) {
        await next();
    }
});

This is exactly the same guidance as given in the OWIN integration guide. As you can see, this is no rocket science. In the future we will publish an integration package that will probably allow you to do this using an extension method. I imagine such extension method to look as follows:

app.UseSimpleInjectorExecutionContextScope();

[pauldotknopf]

You are forgetting that your application code should not have any hard dependencies on external libraries, as the Dependency Inversion Principles prescribes. Whether or not those libraries expose interfaces or just concrete classes doesn't matter. Those abstractions are not tailored to suit our applications’ special needs, so we want to hide those library classes behind application-specific abstractions and have adapter implementations that translate application-specific calls to calls that fit the external tool.

I'm not getting how this applies to the problem. Regardless of how I register my dependencies, I need to take a 3rd party interface as a dependency into my application code.

Where I do this:

public interface IExternalLibraryDependency 
{
   void DoSomething();
}

public interface IMyApplication { }

public class MyApplication
{
  public MyApplication(IExternalDependency externalDependency) { }
}

Or this:

public interface IMyApplicationFacade
{
   void DoSomething();
}

public interface MyApplicationFacade : IMyApplicationFacade
{
   public MyApplicationFacade() { }

  public void DoSomething()
  {
    return ExternalLib.DoSomething();
  }
}

public interface IMyApplication { }

public class MyApplication
{
  public MyApplication(IExternalDependency externalDependency) { }
}

Doesn't matter to me. Regardless though, this is an implementation opinion. I don't like creating facades for 3rd party assemblies in a final/end implementation. I can mock those interfaces for tests, just as easily. To give the user to be able to implement their own IMyApplicationFacade that uses another 3rd party tool doesn't matter for my final implementation. My implementations of 3rd party assemblies are typically the final edge. It is a web app. It does one thing. It does what I want it to do.

When you do that, that external library can use whatever method it likes to manage its dependencies. It can have an internal structure and provide you with facades, or it can hook into the new DI framework if it wishes to do so. In case a facade is used, your adapter will have to call the facade. If that library uses the new DI stuff, your adapter can just resolve such class from the DI infrastructure.

Back to my example for MvcSiteMap though, it is huge. I could register ISiteMapProvider that resolves the implementation from the external lib in it's own way, but it doesn't allow my application to override certain aspects (1 of the 30 interfaces) of MvcSiteMap. It is a reasonable request to have external libraries to be completely registered and used within my DI tool. Here is the argument for the abstraction. MvcSiteMap auto dumping all it's registrations into my DI, and then I can override very small pieces of the external lib.

One of the unique qualities is how its API can prevent problems and on top of that, the Diagnostic system can detect problems at an early stage. Modifying Simple Injector to be more compatible with the new DI abstractions will make Simple Injector loose some of its unique abilities, and this is not something I take lightly.

I just don't get this. I just now replaced SimpleInjector in my project with Microsoft.Extensions.DependencyInjection and every API call was a 1-to-1 mapping. It was easy to change frameworks. With that said though, why can't we develop a ASP.NET 5 DI plugin that forwards each of the abstraction call to the appropriate SimpleInjector registration. The final implementation will still be responsible for storing the container, and it will still have access to the built container (generated from the abstraction). I still don't see why we can't call .Verify() on it and have the same diagnostics. I'm just not seeing the technical hold up.

Think of the abstractions this way.

• I have, use and love SimpleInjector, I use it everywhere in my app, including the core services required by ASP.NET 5 and the runtime. I enjoy .Verify() and all the functionality built-in.
• I need some dependencies.
• I wish to support a "lane of traffic" to my container from 3rd party assemblies.
• These 3rd part assemblies decided it was worth the risk to limit their freedom, and abide by the laws of the road so that they could be quickly implemented/used by anyone who supports retrieving traffic from this "lane".
• My original implementation of SimpleInjector, and all the benefits it gives me, it still there. Nothing is compromised.
• The 3rd party assemblies choose to limit their freedom for users to bring and consume their library quickly with zero configuration.
• Now, I can create a ASP.NET 5 project, add a reference to NuGet packages "SimpleInjector" and "MvcSiteMap" and everything is working together with very minimal configuration.

See the documentation for MvcSiteMap.

They only support advanced scenarios of the entire infrastructure if MvcSiteMap is DI'd into your own container, and you change/override specific services for customization.

If you support this "lane of traffic", I can add all my NuGet packages, and then simply register a single service (single responsibility) from MvcSiteMapProvider to change the functionality to support "advanced" scenarios.

Also, some end users (final implementation) may like the idea of only using the abstraction in their application so that they could switch containers quickly if ever needed. This is a decision that the implementer has made. He/she choose to limit their freedom for the benefit of plug-ability.

[dotnetjunkie]

I just now replaced SimpleInjector in my project with Microsoft.Extensions.DependencyInjection and every API call was a 1-to-1 mapping.

For simple scenarios it looks like it would work out just fine, but as I explained here, there are many both known and yet unknown requirements of the abstractions that just don't map to Simple Injector's API. To sum up a few:

• Simple Injector handles collections of registrations in a completely different way. Issue 41 goes into details about this.
• Simple Injector v3 will not treat open generic registrations as fallback registration by default, while the vNext abstraction consumers will expect fallback behavior.
• Scopes in Simple Injector are ambient, just like .NET’s the TransactionScope. You can never resolve from the scope, you always resolve from the container and the container "knows" within which active scope it is currently running. Passing scopes around is useless.

The three stated incompatibilities are all described in Issue #41, but that’s just the tip of the iceberg. Here’s another one. A quite common use case for Simple Injector users is the registration of composites. Registration of composites is really easy in Simple Injector because of the separation between collections and one-to-one mappings. Here’s how a Simple Injector user would register this:

container.RegisterCollection(typeof(IValidator<>), AppDomain.CurrentDomain.GetAssemblies());
container.Register(typeof(IValidator<>), typeof(CompositeValidator<>));

Batch-registration is used here to register all non-generic implementations of IValidator<T> that are defined in the application as collections of validators. Those registrations can be resolved when calling GetAllInstances<IValidator<X>>() or when a collection type is injected into a constructor. In the second line we register an open-generic one-to-one mapping from IValidator<T> to CompositeValidator<T>. CompositeValidator<T> would typically accept an IEnumerable<IValidator<T>> in its constructor.

Now the big question is, how one would achieve the same with the DI abstractions. In vNext, the last made registration will be used as the one-to-one mapping. In other words, in case you would call app.ApplicationServices.GetRequiredService<IValidator<X>>() you would get the last element of the collection. So we might be tempted to do the following:

descriptors.AddTransient(typeof(IValidator<Customer>), typeof(CustomerValidator));
descriptors.AddTransient(typeof(IValidator<Order>), typeof(OrderValidator));
// etc 
descriptors.Add(ServiceDescriptor.Singleton(typeof(IValidator<>), typeof(CompositeValidator<>));

This however won’t work, because this would cause the CompositeValidator<T> be injected into itself as last element of the supplied collection and this would cause a cyclic dependency. So if we would mimic this append-like behavior that vNext has, we make it much harder for the user to apply the composite pattern in their applications. This would be a severe breaking change for many users that use this pattern, while every alternative method for registering composites would be less obvious.

And these are just a few of the incompatibilities between the new abstractions and Simple Injector. Everything we change in favor of the DI abstraction is a loss for Simple Injector’s users. Not only are these changes to Simple Injector a severe breaking change, users are depending on Simple Injector to help detecting flaws; the separation between one-to-one mappings and collections is just one example. On the other hand, if we would try to let the adapter really ‘adapt’ Simple Injector’s behavior to the DI abstraction (without changing Simple Injector’s behavior), users would see very different behavior when resolving from the adapter compared to when they would resolve from Simple Injector directly. And how should the adapter behave when a library resolves a graph through the DI abstraction that contains objects that are registered directly through Simple Injector’s API? Not only would it be almost impossible to distinguish between the two models, while at the same time keeping invariants such as the guarantee of something being a singleton in place, this all would lead to some very confusing behavior for the ends user, because it some points he himself is using the DI abstractions to register or resolve his types.

Please consider this from our perspective. If we would publish an official adapter implementation, it has to be 100% correct; it’s not good enough that it works in most cases, or just works when making a few simple non-generic one-to-one mappings. It has to have the exact behavior that the vNext abstraction states. This obviously holds for working with collections and generics as well. And while you might only be using the adapter for MvcSiteMap, other developers will start using the adapter for a wide range of other libraries. The number of permutations and possible variations is endless. And unless we comply for 100%, people will run into trouble.

If we would decide to publish such adapter, it means we are committing on maintaining and supporting it for years to come, because there is no use in publishing something that you don’t want to maintain and support. Since we know that we can't create an adapter that is 100% compatible with Simple Injector (without changing Simple Injector into a completely different library), this would mean we would have to spend many hours helping developers who get issues with the adapter. But no matter how hard we try, we won't be able to fix all issues that come up, so there will always be issues that just can’t be solved. This will cause a severe amount of stress to both our users and to ourselves as maintainers. And think about what that would do to Simple Injector’s credibility if we publish some NuGet package that keeps to be broken. I hope you understand that it would be a terrible idea for us to commit to something that we know beforehand won't work and would cause a lot of people pain. We would end up in a much worse place than we are right now.

Do note that even though we will not create, maintain and support an adapter, you are free to define your own, as you already seem to have done. So if that works, because MvcSiteMap’s registrations are really simple, please use that. But hopefully you understand that we can’t ship an adapter implementation that only works for simple registrations. And don’t forget, what works today for MvcSiteMap, might break tomorrow, because MvcSiteMap will expect full compatibility of the DI abstraction it is talking to.

The funny thing though is, that there seems to be a correlation between the incompatibility of Simple Injector with vNext and the love you (and others) express for Simple Injector. As I see it, we love Simple Injector because it approaches things differently than the other DI containers do, and in a way that is really beneficial, and this is what we and our users love about Simple Injector. So although you talk about the "lane of traffic", the reason you are using Simple Injector is because it doesn't follow 'the road', which btw is something that never really existed before. But now, out of the blue, some bright light at Microsoft suddenly decided to define the road and painted some lanes on it. And now suddenly we have to start following these lanes? That seems odd to me.

but it doesn't allow my application to override certain aspects (1 of the 30 interfaces) of MvcSiteMap

Please correct me if I’m wrong, but it seems very unlikely to me that you actually need all 30 abstraction of this external library in your own application. I would say you usually just need a few.

If I upgrade to a newer version of a library that contains 5 more interface/implementations, I won't have to change any of my code.

Since your application doesn't use those new abstractions (since your classes can’t be depending on abstractions that didn’t exist before), you don't have to configure them and you don’t have to change a single thing when a new version of the library comes out. If your application starts to require a new abstraction, you can add it accordingly.

In case creating application-specific adapters is not feasible, I would advise adding those (few) registrations by cross-wiring them. So just let MvcSiteMap register its business in the default DI container, and map it in Simple Injector as follows:

container.Register(app.ApplicationServices.GetRequiredService<ISiteMapProvider>);

It is a reasonable request to have external libraries to be completely registered and used within my DI tool.

I actually find this request unreasonable. If you read the articles from Mark Seemann closely, you see that libraries can be defines in a DI-friendly way (and frameworks as well), where the use of a common abstraction (the Conforming Container is not needed. You’ll see more and more libraries and framework start to use this approach. NServiceBus for instance, is moving away from the Conforming Container anti-pattern. The big problem of course is that the ASP.NET team is pushing really hard to get everybody using their Conforming Container, and that’s why you unfortunately see libraries such as MvcSiteMap jump the bandwagon.

some end users (final implementation) may like the idea of only using the abstraction in their application so that they could switch containers quickly if ever needed. This is a decision that the implementer has made. He/she choose to limit their freedom for the benefit of plug-ability.

This might seem like a great idea at first, but this is a fallacy. The behaviors, APIs and feature sets of the different DI containers are incompatible with each other. In case you have a registration that is simple enough to comply with all DI containers (so simple enough that you can actually swap), there is really no need in using one of the existing DI libraries at all. The vNext container will give you everything you need. Or perhaps Pure DI would be an even be a cleaner option. If you use Simple Injector however, it's probably because of its support of generics, type constraints, decorators and its verifiability. Those types of configurations aren't interchangeable with other DI libraries, since their support for all those features is very limited compared to what Simple Injector offers.

[pauldotknopf]

For simple scenarios it looks like it would work out just fine, but as I explained here, there are many both known and yet unknown requirements of the abstractions that just don't map to Simple Injector's API.

Your right. However, I have (so far) only seen simple usages of the DI (like this). Microsoft is pushing to ensure the lowest common denominator, so they intentionally try to not do advanced things with their container. You have another good point about Microsoft's DI-approach of scopes require you to resolve from a `IServiceScope`` and I think you would agree this is a bad idea, and maybe this is something we can bring to Microsoft's attention. They are really striving to have a LCD. I think there is intention was to support multiple isolated scopes with a single container, but I think they are only using it for a web request, which won't have nested scopes. I think we could being this case up with the ASP.NET team.

Batch-registration is used here to register all non-generic implementations of IValidator that are defined in the application as collections of validators. Those registrations can be resolved when calling GetAllInstances<IValidator>() or when a collection type is injected into a constructor. In the second line we register an open-generic one-to-one mapping from IValidator to CompositeValidator. CompositeValidator would typically accept an IEnumerable<IValidator> in its constructor.

Now the big question is, how one would achieve the same with the DI abstractions. In vNext, the last made registration will be used as the one-to-one mapping. In other words, in case you would call app.ApplicationServices.GetRequiredService<IValidator>() you would get the last element of the collection. So we might be tempted to do the following:

I think this is a non-issue. The only thing we should be focused on is getting SimpleInjector to support the abstractions exactly as stated with the exact behavior expected. These advanced features, the DI framework doesn't intend to support. End-implementations will have access to the Container that was created/generated by the core ASP.NET runtime with simple registrations, but the end-implementation still has access to the container to do whatever they like. Composites, unregistered types, interception, etc.

So, if a user wan'ts to use the following code you provided here:

descriptors.AddTransient(typeof(IValidator<Customer>), typeof(CustomerValidator));
descriptors.AddTransient(typeof(IValidator<Order>), typeof(OrderValidator));
// etc 
descriptors.Add(ServiceDescriptor.Singleton(typeof(IValidator<>), typeof(CompositeValidator<>));

It just won't work. And this is OK. We can make that implied. If a library intends to support the abstraction, they have to adhere to what the abstraction provides. If not, they vendors cannot support the abstraction, they have to leave it up to the users (end-implementations) to register their library correctly using the container of their choice. The abstractions are for a LCD only.

Everything we change in favor of the DI abstraction is a loss for Simple Injector’s users.

I just want to re-iterate. The abstraction is supposed to be LCD. If you can make an argument with Microsoft that they are over-reaching with what is "common", bring it up with them if you haven't already. If they are using composite collections, nested scopes, approach them about it. The .NET stack shouldn't be doing anything advanced, and if it is, it's worth a discussion to have with them.

And how should the adapter behave when a library resolves a graph through the DI abstraction that contains objects that are registered directly through Simple Injector’s API?

This is totally acceptable. If the user leaves the abstraction to do a more "advanced scenario" that involves some interfaces/services from the runtime, I'd expect an explosion if not done properly. The runtime registered services through the abstraction with an expected behavior. If you break it, fine. You broke it. When considering the benefit of using the runtime interfaces/services within my types that I register directory with SimpleInjector, it's worth it.

this all would lead to some very confusing behavior for the ends user, because it some points he himself is using the DI abstractions to register or resolve his types.

I don't think this will be as big of an issue as you'd think. Resolves from the DI vs SimpleInjector should be exactly the same. Currently, it isn't, because of the ambient scopes, but like I said, lets talk to Microsoft about it. Then, the only issue becomes registering.

Please consider this from our perspective. If we would publish an official adapter implementation, it has to be 100% correct; it’s not good enough that it works in most cases, or just works when making a few simple non-generic one-to-one mappings. It has to have the exact behavior that the vNext abstraction states. This obviously holds for working with collections and generics as well.

Absolutely. I wouldn't want it any other way. If we can't get Microsoft to stop doing things that aren't LCD, they fine. If Microsoft can't concede with how they manage scopes, then fine. The point here is finding the flaws with Microsoft's approach, and addressing them. For the benefit of SimpleInjector, it is worth investigating. If we don't at least investigate, you are essentially saying SimpleInjector will never support ASP.NET 5. It is WAY too early for me to say this, and this is probably even an over exaggeration, but you are essentially saying SimpleInjector will never support "MVC", only "WebForms", except with ASP.NET 4, vs ASP.NET 5. Microsoft is investing heavily into .NET DNX, and I have to think that SimpleInjector will just not be an option on the table for most devs. Even me. I fight hard to use this library where appropriate, but it saddens me that I have to change DI containers. You could argue that it can support ASP.NET 5 if you wire up every .NET runtime service manually, but in all likeliness, user's just won't do this.

And think about what that would do to Simple Injector’s credibility if we publish some NuGet package that keeps to be broken.

Absolutely. Like I said. I wouldn't want it any other way. It is just sad for me :(

Please correct me if I’m wrong, but it seems very unlikely to me that you actually need all 30 abstraction of this external library in your own application. I would say you usually just need a few.

If you refer to their documentation, they require DI for any advanced scenario, which I would argue are common scenarios. Here is my wiring of MvcSiteMap for a project that I have using SimpleInjector.

// register MvcSiteMapProvider stuff
container.RegisterSingle<ISiteMapLoader, SiteMapLoader>();
container.RegisterSingle<ISiteMapCacheKeyGenerator, SiteMapCacheKeyGenerator>();
container.RegisterSingle<IMvcContextFactory, MvcContextFactory>();
container.RegisterSingle<ISiteMapCache, SiteMapCache>();
container.RegisterOpenGeneric(typeof(ICacheProvider<>), typeof(RuntimeCacheProvider<>), Lifestyle.Singleton);
container.RegisterSingle<ObjectCache>(() => MemoryCache.Default);
container.RegisterSingle<ISiteMapCreator, SiteMapCreator>();
container.RegisterSingle<ISiteMapCacheKeyToBuilderSetMapper, CustomSiteMapCacheKeyToBuilderSetMapper>();
container.RegisterSingle<ISiteMapBuilderSetStrategy, SiteMapBuilderSetStrategy>();
container.RegisterSingle<ISiteMapFactory, SiteMapFactory>();
container.RegisterSingle<ISiteMapPluginProviderFactory, SiteMapPluginProviderFactory>();
container.RegisterSingle<IAclModule, AclModule>();
container.RegisterSingle<IMvcResolverFactory, MvcResolverFactory>();
container.RegisterSingle<ISiteMapChildStateFactory, SiteMapChildStateFactory>();
container.RegisterSingle<IGenericDictionaryFactory, GenericDictionaryFactory>();
container.RegisterSingle<ISiteMapNodeCollectionFactory, SiteMapNodeCollectionFactory>();
container.RegisterSingle<IUrlKeyFactory, UrlKeyFactory>();
container.RegisterSingle<IUrlPath, UrlPath>();
container.RegisterSingle<IBindingProvider, BindingProvider>();
container.RegisterSingle<IBindingFactory, BindingFactory>();
container.RegisterSingle<IControllerTypeResolverFactory>(() => new ControllerTypeResolverFactory(new string[0], container.GetInstance<IControllerBuilder>(),
    container.GetInstance<IBuildManager>()));
container.RegisterSingle<IActionMethodParameterResolverFactory, ActionMethodParameterResolverFactory>();
container.RegisterSingle<IControllerDescriptorFactory, ControllerDescriptorFactory>();
container.RegisterSingle<IControllerBuilder, ControllerBuilderAdapter>();
container.RegisterSingle(() => ControllerBuilder.Current);
container.RegisterSingle<IBuildManager, BuildManagerAdapter>();
container.RegisterSingle<ISiteMapNodeVisitor, NullSiteMapNodeVisitor>();
container.RegisterSingle<ISiteMapHierarchyBuilder, SiteMapHierarchyBuilder>();
container.RegisterSingle<ISiteMapNodeHelperFactory, SiteMapNodeHelperFactory>();
container.RegisterSingle<ISiteMapNodeCreatorFactory, SiteMapNodeCreatorFactory>();
container.RegisterSingle<ISiteMapNodeFactory, SiteMapNodeFactory>();
container.RegisterSingle<ISiteMapNodeChildStateFactory, SiteMapNodeChildStateFactory>();
container.RegisterSingle<IAttributeDictionaryFactory, AttributeDictionaryFactory>();
container.RegisterSingle<IReservedAttributeNameProvider>(() => new ReservedAttributeNameProvider(Enumerable.Empty<string>()));
container.RegisterSingle<IJsonToDictionaryDeserializer, JsonToDictionaryDeserializer>();
container.RegisterSingle<IJavaScriptSerializer, JavaScriptSerializerAdapter>();
container.RegisterSingle<IRequestCache, RequestCache>();
container.RegisterSingle<IRouteValueDictionaryFactory, RouteValueDictionaryFactory>();
container.RegisterSingle<ILocalizationServiceFactory, LocalizationServiceFactory>();
container.RegisterSingle<IExplicitResourceKeyParser, ExplicitResourceKeyParser>();
container.RegisterSingle<IStringLocalizer, StringLocalizer>();
container.RegisterSingle<ISiteMapNodePluginProvider, SiteMapNodePluginProvider>();
container.RegisterSingle<IDynamicNodeProviderStrategy, DynamicNodeProviderStrategy>();
container.RegisterSingle<ISiteMapNodeUrlResolverStrategy, SiteMapNodeUrlResolverStrategy>();
container.RegisterSingle<ISiteMapNodeVisibilityProviderStrategy>(() => new SiteMapNodeVisibilityProviderStrategy(container.GetAllInstances<ISiteMapNodeVisibilityProvider>().ToArray(), string.Empty));
container.RegisterSingle<INodeKeyGenerator, NodeKeyGenerator>();
container.RegisterSingle<ISiteMapNodeToParentRelationFactory, SiteMapNodeToParentRelationFactory>();
container.RegisterSingle<IDynamicSiteMapNodeBuilderFactory, DynamicSiteMapNodeBuilderFactory>();
container.RegisterSingle<ICultureContextFactory, CultureContextFactory>();
container.RegisterSingle(() => new ISiteMapBuilderSet[]
{
    new AdminSitemapBuilderSet(container.GetInstance<ISiteMapNodeVisitor>(), 
        container.GetInstance<ISiteMapHierarchyBuilder>(), 
        container.GetInstance<ISiteMapNodeHelperFactory>(), 
        container.GetInstance<ICultureContextFactory>()),
    new DefaultSiteMapNodeBuilderSet(container.GetInstance<ISiteMapNodeVisitor>(), 
        container.GetInstance<ISiteMapHierarchyBuilder>(), 
        container.GetInstance<ISiteMapNodeHelperFactory>(), 
        container.GetInstance<ICultureContextFactory>()), 
});

I either use a hold bunch of nested new keywords, or manually wire of each interface myself. As I update MvcSiteMap, I have to manage new/removed registrations. If I supported this LCD "lane of traffic", I wouldn't have to. Notice how they are all simple mappings. This is how ASP.NET should be. If they aren't lets bring it up with them.

In case creating application-specific adapters is not feasible, I would advise adding those (few) registrations by cross-wiring them. So just let MvcSiteMap register its business in the default DI container, and map it in Simple Injector as follows:

This just won't work. Your right in that it get's all those messy un-required registrations out of my container, since my app doesn't use them. But, I NEED another container, outside of MvcSiteMap to support ANY advanced scenario. It makes sense to use the container I am already using (SimpleInjector).

In case you have a registration that is simple enough to comply with all DI containers (so simple enough that you can actually swap), there is really no need in using one of the existing DI libraries at all. The vNext container will give you everything you need.

You are absolutely correct. And, I will probably be using their library for some time to come. I won't be using the StructureMap (or w/e) dnx plugin. I only wished to use SimpleInjector because the performance is through the roof. I've never really been a fan of doing "cool things" with containers, unless absolutely required. I like to avoid unnecessary complexity if at all possible. So, I would say a good portion of people wanting SimpleInjector with the abstration is for the performance boost. Maybe the technical debt gained for such small (but not really IMO) benefit? Idk.

---

Well, I will leave this at that. It is what it is. I will still use SimpleInjector where I can, but future DNX will be a no-go. I'm going to go be sad somewhere. brb :)

[dotnetjunkie]

Your comment amazes me a bit. At one hand you say that we should be 100% compatible, but on the other hand you wave away some arguments, because you see them as advanced scenarios that the DI abstraction is not intended to support. So I'm curious how you think that this is not intended? I never saw such explicit statement from Microsoft of what scenarios exactly are and what aren't supported. As a matter of fact, you can rest assure that when the built-in DI container supports something (or behaves in a certain way) 3rd party developers will start to depend on this at a given moment in time, even if Microsoft would document this somewhere. We can't just ignore this, because users of those libraries will come back for support to us, and we will be forces to -try- fixing it, which will not be possible in all cases.

Despite of our quite elaborate conversation here, I still have the feeling that I didn't manage to get the message across. So for the sake of argument, let’s do an attempt to specify the behaviour of a hypothetical vNext adapter for Simple Injector. To be able to do this, we have to specify some basic rules, to which our adapter must conform. Here are a few:

• We expect any registration made through DNX vNext DI abstractions (or vNext for short), i.e. through the adapter, to be resolved using the vNext behaviour, independently of whether they are resolved through vNext or Simple Injector (SI), and independently of the consumer in which they are injected into.
• We expect any registration made through SI to be resolved using SI behaviour, independently of whether they are resolved through vNext or SI, and independently of the consumer in which they are injected into.
• We expect any configurational change that some third party library makes in a future release that would work when the user uses the built-in vNext container, would also work when using the SI adapter. So using SI should not break the application when the user upgrades one the used libraries.

In other words:

• 3rd party libraries can expect the adapter to conform to the vNext specifications.
• The adapter must be a 100% working implementation. vNext is intended to be the Least Common Denominator, so the adapter must support everything that the abstraction supports. We can't let there be behaviour that is 'undetermined' or 'not supported'. Developers and third parties will start depending on such behaviour anyway.
• Simple Injector users should expect Simple Injector to behave with the expected behaviour and same safety nets as they are depending on today.
• Users should expect to get any library abstraction injected according to what the library specifies through vNext.
• Users should be able to change a library's default configuration through the vNext API.
• Users should be able to change a library's default configuration through Simple Injector and expect Simple Injector behaviour when those new registrations are requested by the library through the vNext adapter.

When looking at both the behaviour of both SI and vNext, this means that we can state the following expectations for a hypothetical adapter:

1. When a library registers a collection of abstraction X (through vNext), and a user registers a type through SI that depends on a single X, the user should expect the last X of the collection to be injected into his component.
2. When a library registers a collection of abstraction X (through vNext), and it registers a component that depends on a single X, it expects the last X of the collection is injected.
3. When a library by default registers no elements of an abstraction Y, and resolves a collection of Y at runtime, it expects to get back null (or perhaps an empty collection; the specs aren't clear about this); but no exception.
4. When a library by default registers no elements of abstraction Y, and the user registers a collection of elements for Y using SI, the library should get those elements when resolving a collection for Y at runtime.
5. When that library decides to registers elements of Y in a next version, while the user already registers a collection of elements using SI (in other words, the user upgrades that library to v2), he should expect his code not to break, and the final collection to contain both his and the library's elements for Y.
6. When a user wants to simplify working with library's abstraction Y by hiding the collection of Y behind a composite (i.e. the composite wraps all elements of Y while presenting the same interface), the user wants to get that composite injected into his components.
7. If a library makes registrations that SI detects as dangerous (such as Captive Dependencies, Short Circuited Dependencies, Torn Lifestyles, Ambiguous Lifestyles or Disposable Transient Components), SI should ignore these registrations, because throwing an exception would break the contract that both the library and the end user depends upon.
8. When the user makes registrations through SI, he expects all his registrations to be checked by SI to prevent those common configuration errors (Captive Dependencies, Short Circuited Dependencies, etc).
9. When a user makes his own registrations through vNext, he expects his registrations to be verified by SI, because not doing so would give him a false sense of security.
10. When a library registers non-generic components based on some open-generic abstraction G (through vNext) and the user registers an open-generic implementation of G as fallback implementation (using SI), the user should expect this same implementation to be returned, even if the library adds its own fallback implementation of G in a future release.

Based on the design of Simple Injector and the vNext behaviour, I would say that these are reasonable expectations for a hypothetical SI adapter. Problem however is that these expectations are conflicting. For instance:

• SI does not allow appending elements to collections using RegisterCollection to allow detecting common programming errors. Instead, SI forces you to call AppendToCollection when appending registrations. This conflicts however with expectation 5, since a configuration using RegisterCollection that would work with v1 of the given library, will fail when upgrading to v2.
• Expectations 2 and 6 are in conflict with each other, since such registered composite should only be injected into components that are registered through SI, while library components registered through vNext should get the last element of the collection (instead of the composite).
• Expectations 8 and 9 are in conflict with each other, since library components registered through vNext are expected to be ignored while diagnosing the container, while user's components registered through vNext are expected to be checked. The abstraction however doesn't allow differentiating between library registrations and user registrations.
• Expectation 10 is in conflict with how the SI API works. Fallback registrations (made using RegisterConditional<T, T>(c => !c.Handled) are handled in order of registration. So if the library adds his own open-generic registration (which the adapter by default should handle as fallback), that library fallback will be picked up before the user's fallback, and will therefore be completely ignored. In vNext however, the last registration will prevail. In a future release SI might even throw an exception when a fallback is detected that was never selected. Both scenarios would mean the libraries v2 would break the user's configuration.

I hope you can see by now that it will be impossible for us to address all those issues.\You may see most conflicts as ‘advanced features’ and therefore non-issues, but ignoring them conflicts being 100% compatibility. And we didn’t even talk about scoping. But perhaps the clearest example is the strictness that Simple Injector forces when it comes to verifying the correctness of the object graph. The built-in DI container does not verify (or care) if you inject a transient instance into a scoped instance, or a scoped instance into a singleton instance. Simple Injector however does not allow this (for obvious reasons), because Simple Injector focusses on productivity of the application developer. Keeping these safety nets in tact is a clear violation of the vNext contract and end users will be affected by this. Removing the safety nets however is a clear violation of Simple Injector’s principles and is in conflict to the expectations that its users have of Simple Injector. This is an unsolvable issue.

I only wished to use SimpleInjector because the performance is through the roof.

If you’re not interested in any fancy features, such as decorator support and diagnostic verification, and only care for performance, the built-in DNX container will be the right tool for you. Its performance is pretty close to what Simple Injector provides.

[pauldotknopf]

Understood.

I would recommend at least maintaining a library that bootstraps all the required runtime components for aspnet vnext, mvc, etc. If a particular stack of .NET cannot be DI'd in SI because of a unavoidable conflict, create a transient registration that Func resolves from the aspnet container. The goal is to allow a simple reference and a single static method to wire everything up. Otherwise, SI will simply not be good choice when writing a vNext application.

I'll go ahead and close this issue.