inversion of control - Designing a Nuget Package with Dependency Injection -

we writing nuget package acts service gateway. responsibility wrap call external service, made in correct way , response dealt correctly. aim reduce dev time overhead when new client wants consume external service.

the nuget package built single project, called 'client', in solution of external service. client project can share common domain , keep build numbers in sync when published. client project applies inversion of control principle, meaning class acting entry point (the start of stack response external service) has number of interface dependencies.

we use strucutremap our ioc container, wondering how configure our client project dependency injection 'built-in'? seems wrong every consumer should have wire dependency resolution package. however, shouldn't case every client should use structuremap , have add 'clientregistry' (initializer) class own start-up logic.

are there guiding principles solve problem? or examples of complex nuget packages built on ioc principle?

you use commonservicelocator - it's not quite rich full ioc container make package container agnostic, , should allow consumers of package continue using ioc container of choice.

the library provides abstraction on ioc containers , service locators. using library allows application indirectly access capabilities without relying on hard references. hope using library, third-party applications , frameworks can begin leverage ioc/service location without tying down specific implementation.