为什么在 SQL Server CLR 中运行的一个函数可能会导致崩溃，而在独立应用程序中运行正常？

Question

下面这两种方法类似，只是一种方法处理空值，另一种则不处理。为了处理空值，它使用 SqlString 类型并检查“get_IsNull”属性。

为什么第一个可能会在 SQL CLR 内运行时导致错误“执行用户定义例程或聚合“CheckMailingAddress”时发生 .NET Framework 错误：.”，而第二个则不会？

特别是，TSQL 错误为 “Msg 10329，Level 16，State 49，Line 1 .Net Framework 执行已中止。”

.method public hidebysig static bool CheckMailingAddress(valuetype [System.Data]System.Data.SqlTypes.SqlString param0) cil managed
{
   .maxstack 8
    L_0000: ldarga.s param0
    L_0002: nop 
    L_0003: nop 
    L_0004: call instance bool [System.Data]System.Data.SqlTypes.SqlString::get_IsNull()
    L_0009: brfalse L_0010
    L_000e: ldc.i4.1 
    L_000f: ret 
    L_0010: ldarga.s param0
    L_0012: nop 
    L_0013: nop 
    L_0014: call instance string [System.Data]System.Data.SqlTypes.SqlString::get_Value()
    L_0019: call class DatabaseValues.MailingAddress DatabaseValues.MailingAddress::op_Explicit(string)
    L_001e: pop 
    L_001f: ldc.i4.1 
    L_0020: ret 
}

.method public hidebysig static bool CheckMailingAddress(string param0) cil managed
{
   .maxstack 8
    L_0000: ldarg.0 
    L_0001: call class DatabaseValues.CheckMailingAddress DatabaseValues.CheckMailingAddress::op_Explicit(string)
    L_0006: pop 
    L_0007: ldc.i4.1 
    L_0008: ret 
}

请记住，据我所知，MSIL 是正确的，因为当在独立应用程序中调用时，这两种方法都有效。仅当在 SQL CLR 内部调用时，两者中的第一个才会崩溃。在 SQL CLR 中，该函数是使用“nvarchar(4000)”类型定义的，据我所知，该类型应该与 SqlString 配合良好。

我可能也可以使用“string”实现第一个方法，并且仍然执行 null 检查，但它使用 SqlString 来利用 INullable 接口属性“IsNull”和“Value”，因为它是通用代码生成器的一部分，而其他可以使用 Sql* 类型。

简单问题总结：

对于那些被方法体中的 MSIL 分散注意力的人；忽略它。我重新编译了这些函数，什么都不做，我的观点是，当输入类型是“SqlString”而不是“string”时，CLR 会崩溃并终止，没有错误消息，并且返回值是 NULL 而不是真的。

//Crashes when input parameter is "SqlString"
.method public hidebysig static bool CheckMailingAddress(valuetype [System.Data]System.Data.SqlTypes.SqlString param0) cil managed
{
   .maxstack 8
    L_001f: ldc.i4.1 
    L_0020: ret 
}

//Doesn't Crash when input parameter is "string"
.method public hidebysig static bool CheckMailingAddress(string param0) cil managed
{
   .maxstack 8 
    L_0007: ldc.i4.1 
    L_0008: ret 
}

Answer 1

我找到了问题的根源，并能够解决它，但我不确定细节。

在某个时候，我将 DeployDatabaseAssembly 项目切换为面向 .NET 4.0，并且 AssemblyBuilder 也必须生成面向 .NET 4.0 的程序集。将项目切换到目标 .NET 3.5 解决了该问题。

有趣的是，包含我所有数据类型的源 DLL (database.dll) 仍然以 .NET 3.5 为目标，并且是故意保留的，因为我知道 SQL Server 现在仅支持 CLR 2.0，这实际上使其与 .NET 4.0 不兼容，因为.NET 4.0 似乎需要 CLR 4.0。使用 ILMerge，我将包含生成函数的动态程序集与现有的 (.NET 3.5) database.dll 相结合。这最终导致了混合程序集 .NET 4.0 程序集，主要基于 .NET 3.5 功能和类。奇怪的是，我能够让使用基本“String”和“int”类型参数的函数正常工作，但 SqlString 类型导致崩溃......显然是因为它是从 .NET 4.0 System.Data.dll 中提取的，因为它在我的 DeployDatabaseAssembly 中被引用为“typeof(SqlString)”，它的目标是 .NET 4.0。奇怪的是，它崩溃了，没有任何类型的错误消息，也没有任何关于它与加载的 SQL CLR 模块不兼容的警告。

我希望我知道一种方法来强制在 .NET 4.0 应用程序中运行的 AssemblyBuilder 生成针对 .NET 3.5 的程序集...

更新：问题彻底解决了

我专注于 ILMerge 的输出，然后继续将 DeployDatabaseAssembly 切换回 .NET 4.0。顺便说一句，我在我的项目中使用 ILMerge 作为参考，因为它是一个 .NET 程序集。

通过像这样设置 ILMerge 选项：

ILMerge merger = new ILMerge();
merger.SetTargetPlatform( "v2", @"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v3.5\Profile\Client");

生成的 DLL 部署到 SQL Server（就像以前一样），但这次实际上运行时没有错误。

有趣的是，如果我仅将目标平台路径中的“v3.5”替换为“v4.0”并尝试将程序集部署到 SQL Server，那么我会在部署期间立即收到一条有用的错误消息“CREATE ASSEMBLY for程序集“我的程序集名称”失败，因为该程序集是为不受支持的 CLR 运行时版本构建的。”。奇怪的是，当我根本没有设置任何目标平台时，它会部署得很好，但在没有任何错误消息的情况下崩溃了。

下表总结了上述配置组合和结果：