问题描述
我在sql Server中使用程序集CLR非常新
是否可以找出用于加载程序集的原始路径?
考虑到这是创建程序集的方式,我需要“从”路径
CREATE ASSEMBLY ClassLibrary1
from 'D:\DotNetTeam\sqlServer\ClassLibrary1.dll'
我之所以这样问,是因为该程序集:a798b6eb4255719355458f3749073dc1b在服务器列表中未找到,并被报告为不安全(我知道我必须对其进行签名,但为此我需要首先找到它)
我发现了另一个问题,但这不是我所需要的。 How to find the assembly registered in SQL Server?
更新
查询sys.assembly_files表时,我注意到该记录存在于此,但不在左侧(对象资源管理器:Assemblies),我是否需要重新创建该程序集?
select *
from sys.assembly_files
where name like 'a79%'
System.IO.FileLoadException:无法加载文件或程序集 'ASSEMBLY_NAME,版本= 0.0.0.0,区域性=中性,PublicKeyToken =空' 或其依赖项之一。发生与安全性有关的错误。 (来自HRESULT的异常:0x8013150A)
System.IO.FileLoadException:无法加载文件或程序集 'ASSEMBLY_NAME,版本= 0.0.0.0,区域性=中性,PublicKeyToken =空' 或其依赖项之一。 HRESULT的异常:0x80FC80F1
解决方法
是,但如果仅通过从文件系统上的DLL加载程序集而通过提供VARBINARY
文字/十六进制字节来否,则仅。从外部DLL(强烈建议反对,btw推荐的方法)加载时,原始路径存储在[name]
的{{1}}列中。
执行以下操作以显示所有可能的路径:
sys.assembly_files
如果程序集是从-- Change this to the assembly name or path to apply filter:
DECLARE @AssemblyName NVARCHAR(260) = '';
-- The content can be used to export the DLL:
SELECT asm.[name] AS [Assembly],afl.[name] AS [PathOrAltName],asm.[permission_set_desc],afl.[file_id],afl.[content]
FROM sys.assembly_files afl
INNER JOIN sys.assemblies asm
ON asm.[assembly_id] = afl.[assembly_id]
WHERE asm.[name] LIKE N'%' + @AssemblyName + N'%'
OR afl.[name] LIKE N'%' + @AssemblyName + N'%'
ORDER BY asm.[name],afl.[file_id];
文字/十六进制字节(即VARBINARY
)中加载的,则0x4D5A9000...
中的[name]
列应与{{ sys.assembly_files
中的1}}列(这是[name]
语句中使用的名称)。
查询
sys.assemblies
表时,我注意到该记录存在,但不在左侧
为清楚起见,问题中的两个屏幕截图都清楚地显示了一长串非常差的名称(很明显以编程方式)的程序集。如果没有CREATE ASSEMBLY
中存在的条目,就不可能以任何方式显示在sys.assembly_files
(或任何其他与装配相关的管理视图)中。
ALSO:确定要与在对象浏览器中向下钻取的查询窗口中的数据库位于同一数据库中吗?
他们只为我提供了数据库备份
程序集实际存在于执行sys.assembly_files
的每个DB中,并显示在sys.assemblies
,CREATE ASSEMBLY
和其他一些系统目录视图中。这是SQLCLR的许多优点之一:程序集并不在数据库外部,而不是现在不推荐使用的外部存储过程API /功能(例如XP)。
我知道我必须签名...
因此,我假设您正在将SQL Server 2017之前的数据库还原到SQL Server 2017或更高版本中。在这种情况下,您确实需要对所有未签名的程序集进行签名,而您不需要则必须对其进行导出( But )(这样做非常容易,这是由于Microsoft误解了该问题)本身,因此提供了与此主题有关的错误文档)。鉴于您可以就地对程序集进行签名以克服新的“ CLR严格安全性”崩溃,因此,这很容易解决:
SQLCLR vs. SQL Server 2017,Part 4: “Trusted Assemblies” – The Disappointment (Msg 10314)
以下是步骤的摘要:
- 使用
sys.assemblies
在包含程序集的数据库中创建证书(使用密码) - 使用
sys.asssembly_files
在大会上签字
- 将证书复制到
CREATE CERTIFICATE ...
(而不是私钥!) - 从证书创建登录名
- 授予基于签名的登录
ADD SIGNATURE TO Assembly::[{assembly_name}] ...
权限 - 您仍然需要确保每个程序集都具有正确的
[master]
,以执行所需的操作
这是该文章中的演示脚本,您可以复制并进行调整以适应您的需求:
Avoiding "Trusted Assemblies" - Demo(在PasteBin上)
有关一般情况下使用SQLCLR的更多信息,请访问:SQLCLR Info
更新(来自O.P。):
问题在于程序集的名称为 ComputeHashFuncAssmembly ,但是路径是包含 a798b6eb4255719355458f3749073dc1b 的路径,因此需要UNSAFE ASSEMBLY
。这也是为什么它在左侧不可见的原因,因为它位于 ComputeHashFuncAssmembly 下,而不是十六进制代码。
我导出了程序集,因为未提供原始DLL,而我想拥有它。
这些是签署大会的步骤
PERMISSION_SET