blog.simpleinjector.orgSimple Injector Blog - Opinions and Best Practice from the Simple Injector

Contributors Simple Injector Blog Opinions and Best Practice from the Simple Injector Contributors Recent Posts: The Tale of the Async Interfaces Simple Injector v5 - Virus edition Simple Injector v4 has been released Working around the ASP.NET Core DI abstraction What’s wrong with the ASP.NET Core DI abstraction? When should you use a container? Simple Injector v3 is here! © 2023. All rights reserved. Powered by Hugo & Strange Case (inspired by Hyde ). The Tale of the Async Interfaces Dec 15, 2020 by Steven With the release of Simple Injector v5, I made an error of judgement. To support asynchronous disposal of the Container and Scope objects I added a dependency from the core library to the Microsoft.Bcl.AsyncInterfaces NuGet package. Unfortunately, this proved to be a very painful mistake. In this blog post I’ll explain why I choose to take this dependency, why this was a mistake, and how this finally got fixed in v5.2 . Double Trouble With the introduction of .NET Core 3, Microsoft added a new IAsyncDisposable interface as asynchronous counterpart of IDisposable . In order enable asynchronous disposal in older framework versions (i.e. .NET Core 2.0 and .NET 4.6.1), Microsoft published the Microsoft.Bcl.AsyncInterfaces NuGet package. Where the package’s net461 and netstandard2.0 targets contain assemblies that specify—among other things—the IAsyncDisposable interface, the netstandard2.1 target assembly uses type forwarding to reference the framework’s version. The publication of the AsyncInterfaces NuGet packages allowed Simple Injector v5.0 to start using the IAsyncDisposable interface. This allowed Simple Injector to asynchronously dispose of classes implementing IAsyncDisposable . It also allowed users to dispose of both Scope and Container in an asynchronous fashion. Historically, the Simple Injector core library hasn’t taken a dependency on an external NuGet package. And for good reason. Because external dependencies can cause conflicts, such as those pesky binding-redirect issues that we’re all too familiar with. This is an unfortunate restriction and there have been many times I wished I could just pull in some external package to simplify my work. The very useful System.Collections.Immutable package is one such example. Unfortunately, there is no easy way of allowing Simple Injector to asynchronously dispose of registered types without taking a dependency on AsyncInterfaces. This left me with two options: Add this dependency to the core and implement asynchronous disposal directly in the core library Create a new NuGet package (e.g., SimpleInjector.Async ) that adds extensions that allow asynchronous disposal of Scope and Container . I decided to go with the first option as the second would result in a less discoverable solution. The former option allows implementing IAsyncDisposable directly on Container and Scope ; the latter would likely rely on extension methods, to allow something similar to the following: await scope.AsAsyncDisposable().DisposeAsync(); . This new feature was implemented and introduced in Simple Injector v5 . This is when the trouble started. Diamonds are forever Within a few days of the release of v5, developers began reporting binding-redirect issues. This was caused by the multitude of versions that exist for the AsyncInterfaces package and its dependencies. Developers were using other libraries and framework parts that took a dependency on AsyncInterfaces, or its dependencies System.Threading.Tasks.Extensions and System.Runtime.CompilerServices.Unsafe . When one of the used application dependencies references a different version of such package (and in particular when the package’s contained assembly has a different assembly version) binding-redirect issues can appear. In an ideal world, the NuGet package manager automatically solves binding-redirect issues for us by adding the required plumbing in the application’s configuration file. But for some reason, the package manager fails to do this. Instead, we have to manually add binding redirects to our configuration files. And this seems especially confusing with regards to AsyncInterfaces and its sub dependencies, as their assembly versions do not match the NuGet package version. The dependency chain of AsyncInterfaces seems to be in the list of common troublemakers . With the introduction of .NET Core, there’s the idea that binding-redirect issues are thing of the past. A more-recent bug report , however, demonstrated that this isn’t always the case, demonstrating that these issues won’t easily go away if we wait long enough. The pain experienced with these dependencies can be solved by setting the correct binding redirects in the application’s configuration file. To help Simple Injector users, I started posting binding direct examples that developers could copy-paste to fix their problem. But even using these examples, developers struggled, and I recently got stuck with this on an application I was developing. Whatever binding redirects I tried, after analyzing the assembly versions of the used NuGet packages, the application would crash with a dreaded Could not load file or assembly X or one of its dependencies” exception. This was the moment that I started to realize the gravity of this Diamond Dependency dilemma that AsyncInterfaces and his little helpers caused. Action was required. This instigator had to go. Diamond Dependency My application took a dependency on both Simple Injector and System.Collections.Immutable. Those two libraries, however, both depended (indirectly) on the previously mentioned CompilerServices.Unsafe. Simple Injector did so via AsyncInterfaces and Tasks.Extensions, while Immutable depended on CompilerServices.Unsafe via System.Memory . This is an example of a Diamond Dependency. A Diamond Dependency is a dependency chain of at least four libraries where library A (e.g. my application) depends on libraries B (Simple Injector) and C (Immutable). B and C than depend on the final library D (Unsafe). A problem emerges when those middle libraries require different versions of this final library D. This is called the Diamond Dependency Conflict. If it quacks like a duck But removing the AsyncInterfaces dependency was easier said than done. Removing the asynchronous disposal feature was not an option; developers already depend on that feature, often—but not always —implicitly by using one of the ASP.NET Core integration packages. And we can certainly expect asynchronous disposal to become more common soon, long before the Diamond Dependency problem will disappear (i.e. before Simple Injector can drop support for .NET 4 and .NET Core 2). Over the last 6 months I have conducted two experiments that tried duck typing to allow removing the AsyncInterfaces dependency from the core library. With duck typing, instead of depending on interfaces, you take a more dynamic approach where you accept any type that conforms to a certain signature. The C# compiler takes this approach in many places, for instance with the foreach , using , and async using keywords. Both trials were discontinued because of the complexity they would introduce into the library, especially when taking performance into consideration. But after I recently experienced the seriousness of the situation myself, I knew removing the party crasher was the only viable solution to this problem. And so, I had to release the Quacken! After multiple days of trying, failing, testing, improving, asking , things started to quack like duck. The meat and potatoes of the implementation is inside the Scope class (which now is littered with compiler directives). Scope now does the following: It tries to figure out if a tracked instance implements an interface named System.IAsyncDisposable”. Whether that interface is The Real Thing ™ or just some self-defined surrogate is irrelevant. If the instance implements that interface, it is stored for disposal, as would happen for ‘normal’...