For the last couple of years Microsoft has been building the latest version of the .NET platform: .NET Core. .NET Core is a complete redesign of the .NET platform, with the goals of being truly cross-platform and cloud friendly. We’ve been following the development of .NET Core closely and have released .NET Core compatible versions of Simple Injector since RC1. With the release of Simple Injector v3.2 we now officially support .NET Core.
As you may be aware Microsoft has added its own DI library as one of its core components. Some would yell “finally!”. The omission of such a component has spawned many open source DI libraries for .NET. Simple Injector obviously being one of them.
Don’t get me wrong here, we applaud Microsoft for promoting DI as a core practice in .NET and it will likely lead to many more developers practicing DI, which is a win for our industry. The problem, however, starts with the abstraction Microsoft has defined on top of their built-in DI container. Compared to the previous Resolve abstractions, such as IDependencyResolver and IServiceProvider, this new abstraction adds a Register API on top IServiceCollection. With the definition of this abstraction, it is Microsoft’s vision that other (more feature rich) DI libraries could plug-in into the platform, while application developers, 3rd party tool builders and framework developers use the standardized abstraction to add their registrations. This would allow application developers a standard for integrating their DI library of choice.
At first sight having an abstraction might seem like sound advice, a common saying in our industry is that there are few problems in software that can’t be solved by adding a (extra) layer of abstraction. In this instance though their reasoning is flawed. DI experts have been warning Microsoft about this problem from the beginning, without success. Mark Seemann quite accurately described the problems with this approach in general here, where IMO the main points of his reasoning are:
- It pulls in the direction of the lowest common denominator
- It stifles innovation
- It makes it more difficult to avoid using a DI container
- It introduces versioning hell
- If adapters are supplied by contributors, the adapters may have varying quality levels, and may not support the latest version of the Conforming Container.
These are real issues we are facing today with the new .NET Core DI abstraction. DI containers often have very unique and incompatible features when it comes to their registration API. Simple Injector, for instance, is very carefully designed in a way that enables the identification of numerous configuration errors. One very prominent example (there are many more) is Simple Injector’s diagnostic abilities. This is one of the features that is fundamentally incompatible with the expectations that consumers of the DI abstraction will have. So what are the expectations consumers will have of the new abstraction?
Consumers of the DI abstraction can be divided into three groups. Framework components, 3rd party libraries and application developers; especially framework components and 3rd party libraries, which are now expected to add their own registrations through the common abstraction. Since it is nigh on impossible for these two groups of developers to test their code with all the available adapters they will test their code with the built-in container. And while using the built in container these developers will (and arguably should) implicitly expect the standardized behaviour of the built-in container – no matter which adapter is used. In other words, it is the built-in container that defines both the contract and the behaviour of the abstraction. Every implemented adapter must be an exact superset of the built-in container. Deviating from the norm is not allowed because it would break 3rd party tools that depend on the behaviour of the default, built-in, container.
Simple Injector’s diagnostic and verification abilities is one of the many features that make Simple Injector users extremely productive. It detects problems that would be detected much later in the development cycle when using a different DI library. But running the diagnostics on both application and 3rd party registrations will cause problems because it is unlikely that all the external parties will automatically “play nice” with Simple Injector’s diagnostics. There is every chance they will define registrations that Simple Injector finds suspicious even though they have (hopefully) tested the registrations are fine for their specific case with the default container. It would be impossible for a hypothetical adapter for Simple Injector to distinguish between 3rd party registrations and application registrations. Switching off diagnostics completely would remove one of Simple Injector’s most important safety nets, whilst leaving the diagnostics system in place would likely cause false-positives from the 3rd party tooling that would each need to be suppressed by application developers. Since these 3rd party registrations are mostly hidden to the application developer, working around these issues could be daunting, frustrating and sometimes even impossible. One might argue that it would be good for Simple Injector to detect problems with 3rd party tools, but contacting those same developers to explain the “problem” would probably lead to fingers being pointed at us, since we “obviously” provided the user with an “incompatible” adapter.
Simple Injector’s diagnostic abilities is just one of the many incompatibilities that we would face when writing an adapter for .NET Core’s DI abstraction. Other incompatibilities include:
- The way Simple Injector explicitly separates the registration of collections from one-to-one mappings
- How Simple Injector handles open-generic registrations; they are not treated as fall-back registrations as they are by the built-in container
- How Simple Injector handles scoping; Scopes in Simple Injector are ambient while .NET Core forces an ambient-less scoping model.
To make a fully compatible adapter for Simple Injector requires removing many prominent features, and thereby changing the existing behaviour of the Simple Injector library to something that would violate the guiding principles that underpin our vision. This is not an attractive solution. Not only would it introduce major breaking changes, it would remove features and behaviours that make Simple Injector unique and it is this complete set of features that many developers love about Simple Injector. In this sense having an adapter “stifles innovation” as Mark describes. With Simple Injector we made many innovations and not only would the adapter make Simple Injector almost useless to its users, it would restrict us from future improvement and innovation. Some might view Simple Injector’s philosophy as radical, but we think otherwise; we designed Simple Injector in a way that we think serves our users best. And the NuGet download count on the Simple Injector package indicates that many developers agree with us. Conforming to a defined adapter would prevent us from serving our users.
Although Simple Injector’s view may diverge from the norm more than most other containers, the simple act of defining this common abstraction blocks future DI libraries with an even more radical or innovative viewpoint from being used at all – it stifles innovation for future libraries. Just imagine one of the other containers introducing the same kind of verification that Simple Injector provides? Such feature can’t be introduced without breaking the contract of the DI abstraction. The mere act of having such an adapter can block progress in our industry.
With this explanation, I hope I’ve also made it clear that Microsoft’s DI abstraction isn’t even the lowest common denominator, because the lowest common denominator implies compatibility with all DI libraries! As I expressed here the chances are that none of the existing DI libraries are fully compatible with the defined abstraction. This is partly down to the fact that although the built-in container defines the contract of the abstraction, the abstraction test project lacks a solid number of test cases that fully define the exact behaviour in all scenarios. Up until now all adapter implementations have been guessing and hoping for the best, that their adapter is mostly in sync with the built-in container’s behaviour. The Autofac maintainers for instance, realized they have some quite severe incompatibility issues and eventually came to the same conclusion as we did. The same holds for the maintainer of StructureMap that more recently stated:
ASP.Net Core DI compliance has been a huge pain in the ass to the point where I’ve openly wondered if the ASP.Net team has purposely tried to sabotage and wipe out all the existing ecosystem of IoC containers
UPDATE: The Autofac maintainers publically stated that their adapter is not 100% compatible with Microsoft’s DI abstraction:
there will definitely be behavior differences between the Autofac DI container and the Microsoft DI container. We’re not trying to behave identically – if you choose to use Autofac as your backing container, you’re also choosing the Autofac behaviors. The difference in behavior you found is one of probably many
This wouldn’t be so bad if Microsoft’s DI library was a feature rich implementation that contained features like Simple Injector’s verification and diagnostic services so that we all use the same fully featured DI library. Sadly, the implementation is far from feature rich, Microsoft itself has described their implementation as a
minimalistic DI container [that] is useful in the cases when you don’t need any advanced injection capabilities
To make matters worse, since the built-in container defines the contract of the abstraction, adding new features to the built-in container will break all existing adapters! Any 3rd party developer who uses the abstraction will only test with the built-in library and when this library depends on a feature added to the built-in container that is not yet supported by an adapter, things will fail and the application developer is screwed. This is one aspect of the versioning hell that Mark Seemann discusses in his blog post. One will hope that, at the very least, Microsoft will bump the major version number any time they make a change. Not only is their current implementation “minimalistic”, it can never evolve to a feature rich completely usable DI container, because they’ve painted themselves in a corner: every future change is breaking change that will piss everyone off.
A better solution is to avoid using the abstraction and its adapters entirely. As Mark Seemann quite accurately explained here and here, reusable libraries and a framework may not need to use a DI container at all. Unfortunately, the mere act of defining an abstraction will make it much harder to avoid using it. By defining an abstraction and actively promoting its use, Microsoft is leading thousands of 3rd party library developers and framework developers to stop thinking about defining the right library and the right framework abstractions (Mark Seemann’s articles clearly describes this). They no longer think about this because Microsoft leads them to believe that the whole world needs one common abstraction. We have seen new factory interfaces for MVC appear very late in the game (such as the IViewComponentActivator abstraction prior to RC2). And if we see the MVC team make these kinds of mistakes till very late in the development cycle, what can we expect from all those developers who are starting to build on top of the new .NET platform?
The definition of a DI abstraction is a painful mistake by Microsoft that will haunt us for many years to come. It has already stifled innovation, has introduced versioning hell and frustrates many developers. The abstraction is incompatible with many DI libraries and, against expert advice, Microsoft chose to retain the abstraction, dividing the world into incompatible and partially compatible containers, leading to endless issue reports for the adapter libraries that implement the DI abstraction and 3rd party libraries that use the abstraction.
Our view is that as an application developer, you should refrain from using an adapter and in the next article I will explain more thoroughly how to approach this and why, even without an incompatible container, it is the smarter way forward.