I am seeing the benefits of Portable Class Libraries for centralizing Models and ViewModels to a single code-base. Where should dependency injection management (IoC container) take place, though? My Models have dependencies that I believe would benefit from being supplied through injection. I'm not sure how to go about "bootstrapping" to set up the container in the portable library, and I also saw some suggestions that a portable library shouldn't have a dependency on a DI framework. Those points have me thinking maybe the DI should be set up in the applications that use my portable library. This seems rather backwards though, requiring someone using the library to add the bootstrapping portion to their application, as well as it would be duplicated in every app that uses the library. Should the library or the application handle DI?

Some specifics on what my environment in question is like: c#, WPF application referencing PCL with Models, ViewModels and core logic. Considering using Autofac for my IoC container.

  • Do you need an IoC container, or would supplying dependencies through the constructors of your objects suffice? Commented Jan 24, 2014 at 22:45
  • @RobertHarvey dependencies through constructors is the way I'm planning to go, but IoC would fulfill those for me. There's a lot of Model generation going on in the library for a complex object-graph.
    – Ethan
    Commented Jan 24, 2014 at 22:51
  • 1
    You should be able to use the IoC container independently of your portable library, but you can use the IoC container with the library by registering the library's interfaces with it. The IoC library can, therefore, live anywhere you want. It seems gratuitous to include a dependency on an IoC container in a portable library, however, unless you expect IoC to be an integral part of the library's functionality. Commented Jan 24, 2014 at 22:57

3 Answers 3


If you need IoC in your library then it may be helpful to provide hooks so a user can use the same containers, but don't require it as the developer may want to use something else.

So make it available since you will include it, but don't limit the programmer's options, if possible.

  • thanks for this response, it looks like I got completely distracted back when i originally posted this and never followed up. Also helpful was softwareengineering.stackexchange.com/a/229087/110552 as an installer module would allow me to wire up the standard implementations of dependencies with hooks for overriding.
    – Ethan
    Commented Mar 22, 2018 at 17:36

We use ninject on an internal project, what I've been doing is setting up an installer module for the libraries so that when I reference them I can just pass it to the kernel setup in the main project.

This seems to be the best of both worlds, there's no real dependency on ninject in the library as you don't need to use the module, it just speeds things up if you are.


No, IoC is outside of the scope of a library usually, as it constricts the use. If the library is only for your own use, of course, you can do anything you wish.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.