Why is IDependencyResolver tightly coupled with System.Web?

Question

Why is the reason the IDependencyResolver is coupled with the System.Web assembly (either Mvc or Http) in the .NET framework ?

The goal of a DI system isn't that it should provide an agnostic way of serving dependencies to a customer ? What if I want to use IDependencyResolver in a project that should not reference anything related to System.Web ?

Edit:
This is more a philosophical question than a request about how to do, because I know there are other alternatives such as open source DI library.

Answer 1

The goal of a DI system isn't that it should provide an agnostic way of serving dependencies to a customer ?

That is correct, but in this case, IDependencyResolver is specific to the library where it is defined. It is that library's DI abstraction to allow an agnostic extensibitliy point for dependency resolution. And I believe that that was the initial goal of the abstraction.

It was not really made to be reused independently by other libraries, which is evident in that there are two versions for both MVC and Web API. Though they share the same name and have the same purpose, their implementations differ slightly.

It also demonstrates the Conforming Container anti-pattern as mentioned in this article by Mark Seemann, where the article also mentions the above abstractions as known examples of Conforming Containers for .NET. Even my preferred approach of using IServiceProvider made the list.

What if I want to use IDependencyResolver in a project that should not reference anything related to System.Web ?

My suggestion then would be to not use IDependencyResolver from System.Web. I would also add that above all, particular attention should be payed to following proper design patterns, making sure that one has an understanding of the concepts and where they should be applied or avoided.