1

至少可以说这让我有点恼火......

我正在将服务层项目升级到 v.next，并在此过程中将我的所有 Linq to Sql 模型“升级”到实体框架。到目前为止，我已经完成了四个数据库，现在正在运行测试 - 我的测试失败并出现错误

System.Data.MetadataException：指定的架构无效。错误：DB.WebDB.ssdl(2,84)：错误 0169：所有 SSDL 工件必须针对同一个提供程序。ProviderManifestToken '2008' 与之前遇到的 '2005' 不同。

做一些谷歌搜索，我发现这通常是由不同的 dev/live sql server 版本引起的。

但是，我的情况有所不同——我有多个运行不同版本的实时数据库服务器——2005、2008 和 2008 R2——我需要能够使用不同的 EDMX 与所有这些服务器通信。

在这个 SO: Multiple Versions of SQL Server using Entity Framework in a single ASP.NET application似乎一种解决方案是将不同版本的 EDMX 拆分为不同的程序集（即 2005 和 2008 版本）。据推测，另一种解决方案将强制我ProviderManifestToken对 2008 年来源的数据库为2005.

然而，对我来说，我必须创建不同的程序集纯粹是为了满足 EF 中的一种行为怪癖，这种行为会使一个 EDMX 破坏所有其他的行为是荒谬的——对我来说，单独的程序集是一种架构决策。同样，破解 EDMX 文件以降级 2008 数据库也是不可取的，尤其是当下一个“从数据库更新...”命令将再次更改它时。

有人有替代解决方案吗？

4

1 回答 1

4

使用 EDMX 和设计器时没有替代解决方案。EDMX 固定为单一数据库实现。在 SQL Server 的情况下，情况更糟，因为 SQL Server 2005 和 2008 的方言之间存在差异（我们可以预期 2012 年即将到来）。一旦您使用 EDMX，这种与数据库实现的紧密耦合就是 SSDL（EDMX 中的数据库描述）的一部分。如果您还使用 VS 中的默认 EF 设计器，则您无法完全控制 SSDL - 当您从数据库更新模型或从模型生成数据库时，它总是会重新创建。

目前的解决方案是：

  • 在开发中使用 SQL Server 2005，VS 设计器不会覆盖您的提供程序清单。此配置也应该适用于 SQL Server 2008 和 2008 R2。
  • 首先使用代码 (EF 4.1 - 4.3.1) 而不是 EDMX，在运行时自动处理
  • 不要使用 VS 设计器并手动维护您的 EDMX 或购买一些更强大的设计器
  • 为 SQL Serve 2005 和 2008 创建单独的 SSDL 部分，并根据使用的数据库实现在连接字符串中正确引用它们。这有许多缺点，例如维护两个几乎相同的 SSDL 文档，并且您不能再次使用 VS 设计器。
于 2012-05-14T08:54:15.937 回答