DbMigrator 的工作原理
我有实例化一个新的代码DbMigrator(new Configuration())
Configuration是 的自定义扩展DbMigrationsConfiguration<T>，其中 T 是DbContext
所以在 内Configuration，有一个 ContextType，它等于<T>。
实例化 DbMigrator 时，它会尝试创建<T>DbContext 的实例。它将尝试在<T>Context 上使用 Empty Constructor，或者它会尝试查找IDbContextFactory<...>where...的实际类型是哪里的实现，而不是泛型 T。
DbMigrator 如何不起作用
问题是，程序集实例化DbMigrator无法访问IDbContextFactory<...>它需要发现的特定类型。另外，我DbContext没有默认构造函数，我不希望它。所以我收到异常The target context '...' is not constructible.
困扰我的是，在我实例化的时候DbMigrator，我已经有一个我正在迁移的实例（或者可能已经在一个实例中） 。DbContext此外，我可以访问IDbContextFactory<T>DbMigrator 内部无法发现的泛型，但我很乐意为它提供一个实例。
问题
那么如何告诉 DbMigrator 要么只使用我的 Context 实例，要么使用我指定的 IDbContextFactory 实例？当它在幕后依靠其神奇的 juju 来尝试发现这些东西（可能使用反射/ServiceLocation）时，它失败了。
我的情况
在一个 AppDomain 中，我使用的是nContexts。我想说一个，但通常是两个，而且可能不止于此。因此，任何依赖于单个应用程序/Web 配置属性或指向单个DbConfiguration 或 ConnectionFactory 的属性装饰器的解决方案都不适合我。因为每个 AppDomain 只能有一个，除非我可以根据我当时需要的上下文来配置它，否则它是徒劳的。所以那里有回旋的余地，但我不知道。
base此外，对于与构造函数相关的 EF，可能有一些我不了解的 juju 。但我不相信将 a 传递给DbConnection构造函数而不是 anameOrConnectionString会起作用。它仍然不是一个空的构造函数。但是，如果 EF 用它来搜索构造函数，以及如何使用它，那可能会起作用。