*我有一个使用 IOC 容器（Autofac，但可以是任何容器）的应用程序。
我也有外部开发的模块。每个模块都需要指定自己的 DI 容器设置，定义存储库，特定于其模块的服务。
在部署时，这些模块会通过 XML 配置手动注册到 Autofac。
通常，如果每个模块都想从 IOC 容器请求一个类型的实例，我们可以使用 ServiceLocator 模式。这将每个模块与特定的 IOC 容器类型分离，例如 Autofac/Unity/StructureMap/等。
但我想在注册时将每个模块与 IOC 容器分离。例如在做 container.Register().As();
所有的 IOC 容器都有不同的方法来实现几乎相同的事情，所以我想知道是否有一个标准模式。
更新：我专门寻找一种方法来不知道类型的注册而不是类型实例的解析。
由于这种情况，服务定位器模式已经失宠。将模块与 IOC 容器解耦绝对是一个好主意，但服务定位器模式意味着它们仍然需要以某种方式引用它。编写自己的通用 IOC 容器包装器不是任何人都应该忍受的任务。
这种情况下更普遍接受的模式是注入模块的依赖项（很可能通过构造函数注入）并且仅在代码的入口点引用 IOC 容器。然后将初始化模块，并满足其所有依赖项。由于 IOC 容器只在一个地方被引用，所以没有必要将它抽象掉。随便挑一个就行，以后改的话，只需要改代码中的一个类即可。
换句话说，每当一个模块向 IOC 容器请求一个对象的实例时，而是将该实例传递给模块的构造函数。如果您需要请求的对象具有运行时依赖项，则改为通过构造函数为它们传递一个工厂。
有关更多详细信息，请参阅这篇文章。
Martin Fowler对服务定位器的看法不那么苛刻，但我认为结论是一样的。
自从这篇文章以来已经有很长时间了，但是我为此目的创建了一个名为“不可知论 IoC”的项目，该项目专门设计用于解决您描述的问题并使用不可知的核心 api 提供设置的能力您的注册，然后在最终实现中使用 nuget 包来解释它。