SQL Server 2017 引入了一个名为“CLR strict security”的新服务器级配置选项，并且默认情况下处于启用状态。此选项要求ALL组件，甚至SAFE，使用证书或强名称密钥进行签名，并且用于执行该签名的证书或非对称密钥加载到[master]，并从中创建了一个登录名，并且该登录名已被授予UNSAFE ASSEMBLY允许。
Due to SAFE程序集现在需要基于签名的登录before正在通过加载CREATE ASSEMBLY，不再可能将空的、已签名的程序集加载到[master] via CREATE ASSEMBLY ... FROM 0x... WITH PERMISSION_SET = SAFE;.
现在，只有两种方法可以创建可用于从 SQLCLR 安全性设置的对象：VARBINARY文字或变量（即not来自外部文件）：
CREATE ASSEMBLY ... FROM 0x...;CREATE CERTIFICATE ... FROM BINARY = 0x...;
选项#1 不再是一个选项，至少它本身不再是一个选项。选项 2 很好，但由于证书未完全集成到 Visual Studio / MSBuild 构建过程中，因此从未成为首选。
幸运的是，有两种方法可以解决这个问题，正如我的以下两篇博客文章中所讨论的：
-
SQLCLR 与 SQL Server 2017，第 2 部分：“CLR 严格安全性” – 解决方案 1 https://sqlquantumleap.com/2017/08/09/sqlclr-vs-sql-server-2017-part-2-clr-strict-security-solution-1/— 比第 3 部分解决方案 2（如下）的步骤更多，但非常适合现有项目，因为它几乎不需要对现有解决方案甚至部署过程进行任何更改（事实上，这实际上是我的路线）SQL# https://SQLsharp.com/?ref=so_46693088项目所做的只是在安装脚本的开头添加 3 个简单的步骤）
- SQLCLR 与 SQL Server 2017，第 3 部分：“CLR 严格安全性” – 解决方案 2 https://sqlquantumleap.com/2017/08/16/sqlclr-vs-sql-server-2017-part-3-clr-strict-security-solution-2/
HOWEVER,
这只是回答了“为什么”您处于当前所处情况的问题。要解决这种情况，假设您可能不会更新 tSQLt 构建过程以包含证书，那么您可以执行一个简单的操作一次性修复：
ALTER DATABASE [master] SET TRUSTWORTHY ON;
EXEC tSQLt.InstallExternalAccessKey;
EXEC master.sys.sp_executesql N'GRANT UNSAFE ASSEMBLY TO [tSQLtExternalAccessKey];';
ALTER DATABASE [master] SET TRUSTWORTHY OFF;
The GRANT UNSAFE ASSEMBLY是否存在由于tSQLt.InstallExternalAccessKey仅授予存储过程EXTERNAL ACCESS ASSEMBLY登录，以前很好，但现在不够了。
当然，在完成这 4 个步骤之前，您将无法加载 tSQLt 程序集，因此，如果该过程是首先加载所有内容并且失败，那么您将需要执行以下操作：
EXEC sp_configure 'clr strict security', 0; RECONFIGURE;
-- Install tSQLt ...
EXEC tSQLt.InstallExternalAccessKey;
EXEC master.sys.sp_executesql N'GRANT UNSAFE ASSEMBLY TO [tSQLtExternalAccessKey];';
EXEC sp_configure 'clr strict security', 1; RECONFIGURE;
我在 tSQLt GitHub 存储库中创建了一个问题，其中包含将理想修复合并到源文件中所需的步骤：https://github.com/tSQLt-org/tSQLt/issues/25 https://github.com/tSQLt-org/tSQLt/issues/25
请注意
这些可能的解决方案都不包括使用新的“受信任的程序集”功能。任何人都不应该以任何理由使用该功能（除了纯粹的好奇心和测试之外）。避免使用它的原因在几篇博客文章中都有详细介绍（目前有 3 篇甚至更多），开头是：
SQLCLR 与 SQL Server 2017，第 4 部分：“受信任的程序集”——令人失望的地方 https://sqlquantumleap.com/2017/08/28/sqlclr-vs-sql-server-2017-part-4-trusted-assemblies-the-disappointment/
