我正在 Microsoft .NET Framework 4.5.2 中编写一个程序集，该程序集定义要在数据库连接两端使用的类型(在数据库内部以及 .NET 上的 DataTable侧)。
服务器正在运行 SQL Server 2008 R2。
SQL Server CLR 版本是 v2.0.50727，Windows 服务器上的 .NET 版本(也包括 2008 R2 版本)是 4.5.2。
由于 CLR 版本的原因，SQL Server 实例仅支持 .NET 3.5 及更低版本。如果不立即升级到 SQL Server 2012，我就无法更改这一点，因为这是一个生产服务器，但我已经围绕 ASP.Net 4.5.2 构建了一个应用程序，我不相信我现在可以更改它以使用 3.5。我对这些类型的经验是，数据连接两端的类型必须相同。
我要么必须强制 4.5.2 类型 .dll 仅限于 CLR v2，强制编译器允许混合版本 .NET 程序集，要么找到另一种方法来绕过 SQL Server 2008 R2 上的 CLR v2 限制。
在我正在处理的时间范围内升级 SQL Server 实例是不可能的。
有人能解决这个问题吗？
更新:
作为解决方案的一部分，我在类型类定义中实现了 IBinarySerialize 和 Serialize 接口(interface)。我在 ToString() 和 Parse 方法中使用 XDocument。
在 .NET 方面，我使用 Dapper ORM 的存储过程调用来执行 CRUD 操作。自定义类型必须使用 ToString() 方法发送到 SQL Server 实例，并由 SQL Server 使用 Parse 方法解析该类型，然后再使用 SQL Server 的 Write 实现进行存储。
使用 Read 方法从记录中获取数据，并使用 ToString() 方法将其发送到 .NET 端。在 .NET 端，.NET 接口(interface)使用 Reflection 使用 Parse 方法将返回结果存储在类型中。
它是反射接口(interface)，它期望 .NET 类型与 SQL Server 程序集类型匹配。发送到 .NET Reflection 接口(interface)的信息包括有关创建发送到 .NET 端的信息的类型程序集的信息。
我想底线是我需要一种方法来欺骗 Reflection 接口(interface)，让它相信使用 .NET 3.5 创建的类型与以相同方式声明的 .NET 4.5.2 类型相同。
最佳答案
鉴于无法绕过 SQL Server 2005、2008 和 2008 R2 的 CLR 2.0 限制，您可能无法在两侧使用完全相同的类型。我从未尝试过混合版本 DLL，但不确定它会在哪里实现，除非您对 CLR 2.0 使用有不同的代码，因为运行的程序集不会有任何“CLR 4.0 或更高版本中的新增功能”可用在 SQL Server 2008 R2 中，在这种情况下，您不妨只编写在 CLR 2.0 中工作的程序集，因为由于向后兼容性，它在 CLR 4.0 中运行得同样好。
您可能会考虑保存可输入任一版本的类型的序列化表示形式，并暂时在 SQL Server 端将其保存为 XML 或 VARBINARY ，目的是在将来SQL Server升级时将该列升级到UDT。但是，您始终可以在构造函数(或其他方法)中读取该序列化值中的 T-SQL 代码。基本上，目前它只需要在数据库方面采取一个额外的步骤。这有道理吗？
关于sql-server - .NET 4.5.2 程序集可以编程为使用 SQL Server 2008 R2 的 CLR 版本 2.0，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49741853/