2010-02-03 59 views
6

我们在安装SQL Server 2005(32位)时使用了一些带有用户定义函数的程序集。我们用这样的脚本将它部署到生产中:CLR程序集将不会加载到64位SQL Server 2005中

CREATE ASSEMBLY [Ourfunctions] 
AUTHORIZATION [dbo] 
FROM 0x4D5A9000...000 
WITH PERMISSION_SET = SAFE 
GO 
CREATE FUNCTION [dbo].[GLOBAL_FormatString](@input [nvarchar](4000)) 
RETURNS [nvarchar](4000) WITH EXECUTE AS CALLER 
AS 
EXTERNAL NAME [Ourfunctions].[UserDefinedFunctions].[GLOBAL_FormatString] 
GO 

我们从来没有遇到过这些函数的任何问题。现在,当我们尝试将我们的一台服务器升级到x64时,我们在调用任何函数时遇到错误。样品堆栈跟踪:

System.Data.SqlClient.SqlException: An error occurred in the Microsoft .NET Framework while trying to load assembly id 65549. The server may be running out of resources, or the assembly may not be trusted with PERMISSION_SET = EXTERNAL_ACCESS or UNSAFE. Run the query again, or check documentation to see how to solve the assembly trust issues. For more information about this error: System.IO.FileLoadException: Could not load file or assembly 'ourfunctions, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047) System.IO.FileLoadException: at System.Reflection.Assembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean -snip-

错误提到权限集EXTERNAL_ACCESSUNSAFE,而我们使用的水平SAFE

该.dll文件是建立与目标平台设置为'任何CPU',当我们尝试从文件而不是varbinary语法加载dll时,我们会得到相同的结果。我们已经尝试了http://support.microsoft.com/kb/918040的建议

我们已经在32位机器上尝试了完全相同的过程,并且一切都正常。它必须是x86和x64之间的区别。有任何想法吗?

解决方案:我们终于找到了解决方案。事实证明,我们的程序集确实是一个32位编译的程序集。在Visual Studio中,我们所使用的目标“任何CPU”,但在检查底层的.csproj,我发现下面的代码片段:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> 
    ...other elements... 
    <PlatformTarget>x86</PlatformTarget> 
    </PropertyGroup> 

所以我们的“任何CPU”的目标实际上是建立一个x86汇编! Aaargh。我已经在颠覆中追溯了这条线,但是它在2006年首次签入时已经存在。也许这是数据库项目早期模板中的一个错误?

无论如何,感谢您的帮助。我会接受拉斯的回答,因为我怀疑许多遇到同样问题的人最能得到他的回答。

回答

0

它并不是与它是64位的事实有关,您需要更改数据库以允许它。试试这个:

ALTER DATABASE YOURDATABASEHERE 
SET TRUSTWORTHY ON; 
GO 

如果单独不工作,你可以尝试以下几种以及

USE YOURDATABASEHERE 
GO 
sp_configure 'show advanced options', 1; 
GO 
RECONFIGURE; 
GO 
sp_configure 'Ole Automation Procedures', 1; 
GO 
RECONFIGURE; 
GO 
+0

我们已经做了TRUSTWORTHY选项,它在KB918040中提到。我们会尝试其他选项。感谢回复。 – 2010-02-04 10:57:28

0

你可以尝试从文件加载程序集。我不确定是否可以使用编码字符串语法将32位版本上的汇编代码部署到64位SQL Server。

+0

是的,我们尝试过,但没有成功。顺便说一下,编码表单与文件表单一样可移植。我们找到了根本原因。将添加我的问题的答案。 – 2010-02-10 14:07:09

相关问题