On a recent project I have been working on we’ve had a dilemma with how to register dependencies in libraries that our application consumes but does not own. The development of these libraries is under our control, but separate from the top level consuming application’s development. Using dependency injection at all in our environment was very controversial, and now we are experiencing similar controversy regarding how to manage the dependencies of the libraries we consume when they are also using dependency injection.
The problem appears to be how to coherently register implementations that are not in assemblies that are referenced by the top level application. My thought is that the top level app should call registration modules in the assemblies it does references and allow those routines to register types in assemblies they reference, this would allow the top level application to be free of references to assemblies it doesn’t directly know about. Others believe the top level application should register all implementations discreetly so should have a reference to all assemblies that hold types that the application will eventually use. I can see how that is appealing, but I tend to think of what my application is consuming as being more plugins and I’d like the top level application to not have to care so much about the details of their implementations.
Perhaps the right answer is to have separate containers for things I want to be considered plugins and let them register what they need without having the top level application aware of it at all?