SQL Server 2017 CLR 错误：无法在程序集中找到类型答案

【问题标题】：SQL Server 2017 CLR Error: Could Not Find type in assemblySQL Server 2017 CLR 错误：无法在程序集中找到类型
【发布时间】：2020-04-04 23:46:29
【问题描述】：

我正在 SQL Server 2017 中创建 CLR 存储过程。我在以前的版本中已经多次这样做了，没有任何问题；但是，我们最近更新到 SQL Server 2017。

我知道这次升级带来的安全问题，但我想确保在我开始搞乱安全之前我可以部署我的 CLR。我创建了一个名为Test 的数据库并将Trustworthy 设置为ON（我知道这很糟糕——临时的）。我不断收到以下错误：

在程序集“Get_API_Data”中找不到类型“CLR_Get_API_Data.StoredProcedures”。

我发现了几篇文章，例如：SQL Server: Could not find type in the assembly 处理了这个错误，但他们将代码构建在一个类中，而不是 storedProcedures 类型的部分类。

这是我创建存储过程的 SQL 脚本：

USE Test 
GO

--Alter Database Test
--Set Trustworthy on

--EXEC sp_configure 'clr strict security', 1;
--RECONFIGURE;

IF EXISTS (SELECT * FROM sys.assemblies asms 
           WHERE asms.name = N'Get_API_Data' AND is_user_defined = 1)
    DROP ASSEMBLY [Get_API_Data]
GO

CREATE ASSEMBLY Get_API_Data
FROM 'C:\Users\Administrator\Documents\Visual Studio 2015\Projects\CLR_Assemblies\Get_API_Data\Get_API_Data\bin\Debug\Get_API_Data.dll'
WITH Permission_Set = Safe --EXTERNAL_ACCESS 
GO

--Assembly Name,[SolutionName.StoredProcedures].Sub Name
CREATE PROCEDURE [dbo].[GetAPI]
AS EXTERNAL NAME Get_API_Data.[CLR_Get_AMS_API_Data.StoredProcedures].GetAPI
GO

我的解决方案名称是CLR_Get_API_Data，我的项目名称是Get_API_Data，我的方法名称是GetAPI。以下是我的 Visual Studio 代码：

using System;
using System.Data;
using System.Data.SqlClient;
using System.Data.SqlTypes;
using Microsoft.SqlServer.Server;
using System.Net;
using System.IO;

public partial class StoredProcedures
{
    [Microsoft.SqlServer.Server.SqlProcedure]
    public static void GetAPI ()
    {
         // Stuff happens here
    }    //Ends Public Void Get
}    //Ends Class

【问题讨论】：

标签： sql-server sqlclr

【解决方案1】：

使用部分类没有错。

[CLR_Get_AMS_API_Data.StoredProcedures] 的 CLR_Get_AMS_API_Data 部分指的是命名空间名称。您的代码没有显示您正在使用命名空间。删除CLR_Get_AMS_API_Data.，留下：

AS EXTERNAL NAME Get_API_Data.[StoredProcedures].GetAPI

有关在 SQL Server 2017 及更高版本中正确/安全地部署 SQLCLR 项目的更多信息，请参阅我的帖子：

SQLCLR vs. SQL Server 2017, Part 2: “CLR strict security” – Solution 1 — 比第 3 部分，解决方案 2（下）更多的步骤，但非常适合现有项目，因为它几乎不需要更改现有解决方案甚至部署过程（事实上，这实际上是我走的路线对于我的 SQL# 项目，它所做的只是在安装脚本的开头添加 3 个简单步骤）
SQLCLR vs. SQL Server 2017, Part 3: “CLR strict security” – Solution 2

有关使用 SQLCLR 的更多信息，请访问：SQLCLR Info

【讨论】：