title: Writing a library that is dependency-injection "enabled"
body: <p>I'm working on a project at the moment and it's going to be primarily library-based.</p>
  
  <p>I want the library to be consumed using dependency injection, but I want the library to be largely agnostic towards the container being used.</p>
  
  <p>I wrote a "bridge" library a while back to make this sort of thing easier, but I wasn't sure if this was actually the right approach? (library: <a href="https://github.com/clintkpearson/IoCBridge" rel="nofollow">https://github.com/clintkpearson/IoCBridge</a>)</p>
  
  <p>I don't want to reference the DI-technology (Ninject, Windsor etc) directly from my library as then it makes it inflexible for people using it.</p>
  
  <p>There are a few other questions on SO in a similar vein but none of them seem to actually address the problem satisfactorily.</p>
  
  <p><strong>As a side note</strong>: I realise I could just make sure the library adheres to the general idiom and uses interfaces &amp; ctor arguments for dependencies, and then just leave it up to the consuming app to register the types in the containers.</p>
  
  <p>The only issue I can see with this (and correct me if I'm wrong) is that this requires the consuming app to actually <strong>know</strong> which types link to which interfaces, whether some need to be registered as singletons etc... and from a plug-and-play usage perspective that's pretty poor.</p>