我们目前正在编写一个充当服务网关的 nuget 包。它的职责是结束对外部服务的调用，以便以正确的方式进行并正确处理响应。其目的是减少新客户端想要使用外部服务时的开发时间开销。
nuget 包是从外部服务解决方案中称为“客户端”的单个项目构建的。这样客户端项目就可以共享一个公共域，并在发布时保持内部版本号同步。客户端项目应用控制反转原则，这意味着作为入口点的类（从外部服务获取响应的堆栈的开始）具有许多接口依赖项。
我们通常使用 StrucutreMap 作为我们的 IoC 容器，但我想知道我们如何使用“内置”依赖注入来配置我们的客户端项目？每个消费者都应该为包连接依赖解析似乎是错误的。但是，也不应该是每个客户端都应该使用 StructureMap 并且必须将“ClientRegistry”（初始化程序）类添加到自己的启动逻辑中。
是否有任何指导原则可以帮助解决这个问题？或者任何基于 IoC 原则构建的复杂 nuget 包的好例子？
You could use CommonServiceLocator - it's not quite as rich as a full IoC container but it will make your package container agnostic, and should allow consumers of your package to continue using the IoC container of their choice.
The library provides an abstraction over IoC containers and service locators. Using the library allows an application to indirectly access the capabilities without relying on hard references. The hope is that using this library, third-party applications and frameworks can begin to leverage IoC/Service Location without tying themselves down to a specific implementation.