我有实例化新DbMigrator(new Configuration())的代码
Configuration是DbMigrationsConfiguration<T>的自定义扩展，其中T为DbContext
因此，在Configuration中存在一个ContextType，它等于<T>。
实例化DbMigrator时，它将尝试创建<T> DbContext的实例。它将尝试在<T>上下文中使用Empty构造函数，或者尝试寻找IDbContextFactory<...>的实现，其中...是T的实际类型，但不是通用T。
问题是，实例化DbMigrator的程序集无法访问它需要发现的特定类型的IDbContextFactory<...>。另外，我的DbContext没有默认的构造函数，我也不想这样做。所以我收到异常The target context '...' is not constructible.
困扰我的是，在我实例化DbMigrator时，我已经有一个实例（或者可能已经在 内）我正在迁移的DbContext中。另外，我可以访问DbMigrator内部无法发现的通用IDbContextFactory<T>，但我很乐意为其提供实例。
那么如何告诉DbMigrator仅使用我的Context实例，还是使用我指定的IDbContextFactory的实例？当它依靠其幕后的魔术来尝试发现这些东西（大概是使用反射/ ServiceLocation）时，它就失败了。
在一个AppDomain中，我正在使用n上下文。我想说一个，但通常是两个，可能不止于此。因此，任何依赖于单个 app / web config属性或指向单个 DbConfiguration或ConnectionFactory的属性装饰器的解决方案都将不适用于我。因为每个AppDomain只能有一个，并且除非我可以根据当时所需的上下文进行上下文配置，否则它是徒劳的。所以那里有一个摆动的房间，但我不知道。
此外，关于base构造函数的EF，可能还有一些我不了解的地方。但是我不相信将DbConnection传递给构造函数而不是nameOrConnectionString是可行的。它仍然不是一个空的构造函数。但是，如果EF做了一些事情来搜索构造函数，以及如何利用它，那MIGHT就可以了。