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

오류는 우리가 수준 SAFE를 사용하는 반면, 권한이 EXTERNAL_ACCESSUNSAFE를 설정 언급하고있다.

.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"대상이 실제로 86 어셈블리를 구축했습니다! 아아. 전 Subversion에서이 줄을 추적했지만 2006 년 처음 체크인했을 때 이미있었습니다. 아마도 이것은 데이터베이스 프로젝트의 초기 템플릿의 버그 였을까요?

어쨌든 도와 주셔서 감사합니다. 저는 러스의 대답을 받아 들일 것입니다. 같은 문제를 경험하는 많은 사람들이 그의 대답으로 가장 도움이 될 것으로 생각합니다.

답변

0

사실 64 비트 일 필요는 없습니다. 허용하려면 DB를 변경해야합니다. 혼자가 작동하지 않을 경우,

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에 언급되어 있습니다. 우리는 다른 옵션을 시도해 볼 것입니다. 답장을 보내 주셔서 감사합니다. –

0

당신은 파일에서 어셈블리를로드 할 수뿐만 아니라 이러한 옵션을 시도 할 수 있습니다 :이보십시오. 인코딩 된 문자열 구문을 사용하여 32 비트 버전에서 64 비트 SQL Server로 인코딩 된 어셈블리를 배포 할 수 있는지 확실하지 않습니다.

+0

그래, 우리는 그것을 시도했지만 성공하지 못했다. 인코딩 된 형식은 파일 형식과 같이 이식성이 뛰어납니다. 근본 원인을 찾았습니다. 내 질문에 답을 추가 할 것입니다. –

관련 문제