是否可以在 SQL Server 2014 中为 .NET 框架程序集创建非对称密钥？

我正在 Visual Studio 中开发一个 SQL Server 数据库项目，它实际上是一个用户定义函数。在此项目中，我包含 Json.NET 作为参考（使用 NuGet）。

我设法通过首先打开数据库将我的程序集和 UDF 发布（并使其工作）到我的 SQL Server 实例TRUSTWORTHY ON（因为我的项目不安全）然后运行：

CREATE ASSEMBLY [System.Runtime.Serialization] 
FROM 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Runtime.Serialization.dll'
WITH PERMISSION_SET = UNSAFE;

结果是 Json.NET 依赖的程序集（如果我不这样做，就会收到错误）

同时我读到过开启“信任”有多糟糕我试着使用非对称密钥避免打开它的方法。

在签署我自己的程序集之前，我知道我必须为System.Runtime.Serialization因为我的项目依赖于 Json.Net，而 Json.Net 又依赖于它，但是当我运行它时，我得到了这个：

USE [master];
GO
  CREATE ASYMMETRIC KEY [SystemRuntimeSerializationKey]
    AUTHORIZATION [dbo]
    FROM EXECUTABLE FILE = 'C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Runtime.Serialization.dll';
GO

Msg 15468, Level 16, State 5, Line 3
An error occurred during the generation of the asymmetric key.

这对我没有多大帮助。

那么是否可以为 .NET 框架程序集生成这样的密钥，或者是否存在除打开 TRUSTWORTHY ON 之外的解决方法？

不，我从来没有找到实现这一目标的方法。用于签署 .NET Framework 程序集的密钥是 Microsoft 内部/私有的。尝试过的选项：

• 提取私钥/加载到 SQL Server：不可能，否则密钥将不是“私有”的。签名/强命名系统是有效的，因为外部人员不能声称他们签署了代码。

• 添加签名：我尝试使用添加新签名sn公用事业。不起作用，因为：

  无法重新签署程序集 - 程序集的公钥与签名公钥不匹配。

  但是，即使这确实有效，也可能并不意味着将其加载到 SQL Server 中就可以工作，因为它与您作为资源添加到项目中的程序集不同。其他 .NET Framework DLL（如果有任何其他依赖项）只会知道原始签名。

• 删除当前签名并添加新签名：我尝试使用ILDASM拆解System.Runtime.Serialization.dll，然后添加从创建的新私钥sn -k然后使用重新链接ILASM，但是失败了ILASM步骤（我没有时间进一步调查）。

  但就像上面的选项一样，即使这确实有效，您也必须更改 Json.NET 项目引用System.Runtime.Serialization要成为这个新的 DLL，请重新编译它，然后将项目引用更改为新的 DLL，然后重新编译它。但这只能让您能够干净地加载 DLL，如果它们具有需要原始 Microsoft 签名的外部依赖项，则不能保证它们能够正常工作。

本质上，如果您正在加载无法控制签名的 DLL，那么唯一的希望就是使用ILDASM并使用重新编译ILASM，指定一个新的snk文件，但如果其他程序集链接到正在重新编译的内容，则该方法将不起作用。当然，.NET Framework DLL 就属于这一类。

简而言之：如果您正在加载不受支持的 .NET Framework DLL，那么您非常需要设置TRUSTWORTHY ON.

BUT：请记住，即使这确实可以通过非对称密钥或证书加载所有内容，但这并不意味着您不会遇到功能问题。这些库尚未获得批准/验证是有原因的。其中的代码可以以您意想不到的方式执行一些操作，例如将数据存储到静态字段。在 Windows 和控制台应用程序中，这不是问题，因为每个应用程序域只能使用一次。但 SQLCLR 使用共享应用程序域，因此多个 SQL Server 会话将共享这些静态变量。可能 Json.NET 库调用的方法没有使用那些不安全的东西，但我们无法知道，即使我们知道，现在我们也无能为力:-(。

我一直在考虑的一件事是跟踪不受支持的 .NET Framework DLL 中调用的方法，并假设它没有执行任何不安全的操作，从而将该代码直接复制到项目中。理论上这应该有效，只要调用System.Runtime.Serialization不要调用其他不受支持的 DLL 或做“不安全”的事情等。但是，我还没有时间对此进行测试。