2010-02-03 57 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

相關問題