MSLinqToSQLGenerator生成的输出与SQLMetal不同

Question

我有一个相当大的DBML文件，最近发现Visual Studio的MSLinqToSQLGenerator生成的输出不同于：

SqlMetal.exe All.dbml /code:All.designer.vb /namespace:LINQ2FSE /pluralize /provider:SQL2005

它似乎从生成的VB代码中删除了一组任意的(我认为是相对较小的)关联。但是SQLMetal运行得很好。输出不应该是相同的吗？

经过进一步的研究，我发现不同之处似乎在于实体上的关联，这些实体涉及的属性也用于具有不同列数的同一实体上的其他关联。例如:实体A具有列id和名称实体B具有列id、name和fkA (A的外键)实体C具有列id、name、fkA和fkB (可为空的fkB)

实体C具有将fkA链接到A.id的关联C_A，还具有将fkA和fkB链接到B.fkA和B.id的关联C_B

支持C_B的属性的代码不会由Visual Studio生成，而是由SqlMetal.exe生成。

这种关联是允许的吗？是否存在代码生成方式不同的原因？

Answer 1

事实证明(在微软的帮助下)，SQLMetal生成的输出与集成开发环境的MSLinqToSQLGenerator不同，因为DBML文件(由我创建的工具生成)定义了一些关系，父对象可以在其中访问子对象，但子对象没有定义父对象关联。显然，您需要定义从子对象到父对象的关联(外键关系)。如果您只定义了从父级到子级的关联，而没有定义反向关联(或者反向关联具有不同的名称)，那么该关联的.NET源代码将不会在这两个方向上生成。对于MSLinqToSQLGenerator，这是正确处理的，但是SQLMetal显然不会执行那么多的验证，而且无论如何都会生成关联代码。Microsoft已将此问题报告给开发人员。