title: Designing a Nuget Package with Dependency Injection
body: <p>We are currently writing a nuget package that acts as a service gateway. Its responsibility is to wrap up the call to an external service, so that is made in the correct way and the response is dealt with correctly. Its aim is to reduce the dev time overhead when a new client wants to consume the external service.</p>
  
  <p>The nuget package is built from a single project, called 'client', in the solution of the external service. This is so the client project can share a common domain and also keep build numbers in sync for when it is published. The client project applies the inversion of control principle, meaning that the class acting as the entry point (the start of the stack to get a response from the external service) has a number of interface dependencies.</p>
  
  <p>We usually use StrucutreMap as our IoC container, but I am wondering how we configure our client project with dependency injection 'built-in'? It seems wrong that every consumer should have to wire up dependency resolution for the package. However, it also shouldn't be the case that every client should use StructureMap and have to add the 'ClientRegistry' (initializer) class to its own start-up logic.</p>
  
  <p>Are there any guiding principles to help solve this problem? Or any good examples of complex nuget packages that are built on the IoC principle?</p>