我需要使用SQLCLR来创建一个使用.NET 3.5中的东西的存储过程。如果我不使用PERMISSION_SET = UNSAFE我不能这样做，它会死，并给我这个错误：
部署错误SQL01268：.Net SqlClient 数据提供者：Msg 6503，Level 16，State 12，Line 1 程序集'system.core，version = 3.5.0.0，culture = neutral，publickeytoken = b77a5c561934e089。'在SQL目录中找不到。 批处理执行时发生错误。
所以我找到了这篇文章：
最后一行说明了这一点：
“现在DBA肯定不会让我使用它，但构建它很有趣。”
我不确定他是否将权限设置为“不安全”。
那么，如果你这样做，会发生一些巨大的漏洞吗？
有三种不同的permission_set选项可以限制程序集的功能
SAFE - 将程序集限制为托管代码
EXTERNAL_ACCESS - 允许访问文件，网络资源等。
UNSAFE - 不受限制的访问 - 包括执行非托管代码
MSDN文档提供以下指导
通过指定UNSAFE，可以使程序集中的代码完全自由地在SQL Server进程空间中执行可能会损害SQL Server健壮性的操作。 UNSAFE程序集还可能破坏SQL Server或公共语言运行库的安全系统。 UNSAFE权限只应授予高度可信的程序集。
如果您的程序集仅使用.NET 3.5的功能，我不明白为什么它需要UNSAFE访问。
您可能正在使用System.Core库中不允许的类型或成员之一。微软有这些列表。 Disallowed Types and Members in System.Core.dll
这里有更多信息。 Host Protection Attributes and CLR Integration Programming
接受的答案对于三个安全级别是正确的，但是关于在这里需要UNSAFE的原因不正确。
实际上有两个问题要问：
PERMISSION_SET = UNSAFE是否安全？
无论一些人会抱怨什么，UNSAFE安全级别没有任何内在的错误或“不安全”。 UNSAFE权限集允许人们做更容易破坏系统安全性和/或稳定性的事情，但没有任何东西说所有被认为“不安全”的功能都会产生影响。而且，编写不良的查询/存储过程/函数会对系统性能和稳定性产生负面影响。仅仅因为某个功能可以被滥用并不意味着它无法正确使用来做出令人敬畏的事情。
SQL Server的CLR主机与主Windows OS CLR主机分开（两者都是或应该与ASP.NET CLR主机分开）受到高度限制，它们只包含.NET Framework的一小部分。包含的库（可以在这里找到：Supported .NET Framework Libraries）保证可以在SQL Server的更新和服务器级别的.NET Framework更新（即补丁，升级等）上工作。还有其他库不在该列表中，就其所做的事情而言完全“安全”使用，但是由于不在“支持”列表上，它们需要注册为UNSAFE，因为它们还没有经过测试，无法保证在.NET Framework更新中保持可用。例如，我相信，ServiceModel是.NET 2和3中的纯MSIL库。但是，它从.NET 4开始变为混合模式（即包含一些非托管代码），并且因为SQL Server 2012和更新版本仅链接到CLR v4，再次编写的ServiceModel Web服务代码，在2012版之前的SQL Server版本中运行得非常好，从2012版本开始停止工作。PERMISSION_SET = UNSAFE，为什么我会收到提及system.core的错误？
此问题特定于SQL Server 2005. SQL Server 2005是第一个包含对.NET功能（即SQLCLR）支持的版本。 .NET Framework 2.0中不存在System.Core库，直到2006年底才发布.NET Framework 3.0（请参阅：.NET Framework version history）。由于这个时间，System.Core不能包含在SQL Server 2005的CLR主机中。但是，由于.NET 3.0和3.5使用CLR v2，就像.NET Framework 2.0一样，可以在SQL Server 2005如果将程序集设置为UNSAFE，它允许查看SQL Server的内部CLR主机。
SQL Server 2008和2008 R2都在其内部CLR主机中包含.NET Framework 3.5，并且他们在“支持”列表中添加了两个库，一个是System.Core。因此，对于这两个版本，您可以在SAFE程序集中使用System.Core中的功能。而且，这就是System.Core位于“支持的.NET Framework库”列表（上面链接）的底部的原因。有关与SQLCLR相关的.NET细微差别的更多信息，请参阅我的文章Stairway to SQLCLR Level 5: Development (Using .NET within SQL Server)以及SQL Server Central上的整个“Stairway to SQLCLR”系列。
有关使用SQLCLR的更多信息，请访问：SQLCLR Info
很抱歉要说明这一点，但“UNSAFE”的哪一部分难以理解？
您可以：
我假设您的问题"How to make this CLR work with 2005?"与您想要使用可能具有后两种副作用的方法有关...