首先使用EF代码，我们有一个数据库种子框架，它使用依赖注入的db初始化器和种子程序来用示例测试数据填充dev数据库。
其中一些种子设定操作需要导入大量数据，因此对于一些表，我们使用带有INSERT语句的实际SQL文件。对于其中一些插入语句，必须禁用外键，然后重新启用：
ALTER TABLE [Schema].[TableName] NOCHECK CONSTRAINT [TableName_FkPropertyName]
-- perform a block of inserts
ALTER TABLE [Schema].[TableName] CHECK CONSTRAINT [TableName_FkPropertyName]
我刚刚从EF 4.2更新到EF 4.3，注意到这些已经不起作用了。对EF创建的数据库的检查表明，FK的名称现在有所不同：
FK_CodeFolder1.Table1Name_CodeFolder2.Table2Name_DbFkColumnName
有没有什么方法可以删除这种命名约定并返回到原始名称？如果不是，这怎么不是一个已知的问题或突破性的变化？
Ladislav回复后的更新
拉迪斯拉夫是对的，我上面对新命名模式的解释并不完全正确。我已经更新了它。前面的部分。不是完整的命名空间，但它是实体模型项目中文件夹的名称。因此，如果我在AggregateSet1文件夹中有一个实体WidgetAbc，那么fk模式片段将是AggregateSet1.WidgetAbc，而不仅仅是WidgetAbc。
为什么你认为这是一个问题或破坏性的更改？IMHO，这是EF的内部行为-您首先使用代码，在这种方法中，您不应该直接使用数据库，尤其是您不应该将自定义数据库脚本基于硬编码名称，因为您无法控制它们的生成。
我不认为您可以恢复行为，但您可以开始使用迁移并对表定义进行编码-AddForeignKey方法应该允许您命名FK约束。
Btw。我在EFv4.3.中看到了FK约束的不同命名模式
FK_DependentTableName_PrincipalTableName_FKColumnName