El ensamblaje de CLR no se cargará en 64 bits SQL Server 2005

Question

Usamos un ensamblaje con algunas funciones definidas por el usuario en nuestra instalación de SQL Server 2005 (32 bits). Implementamos esto en producción con un script como este:

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 

Nunca hemos tenido ningún problema con estas funciones. Ahora, cuando intentamos actualizar uno de nuestros servidores a x64, recibimos errores al llamar a cualquiera de las funciones. Muestra seguimiento de la pila:

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-

El error menciona el permiso establece EXTERNAL_ACCESS Y UNSAFE mientras que nosotros usamos el nivel SAFE.

El archivo .dll se compila con la plataforma de destino establecida en 'Cualquier CPU' y obtenemos los mismos resultados cuando intentamos cargar el dll desde el archivo en lugar de la sintaxis varbinary. Ya probamos las sugerencias en http://support.microsoft.com/kb/918040

Hemos intentado exactamente el mismo procedimiento en una máquina de 32 bits y todo ha funcionado. Debe ser una diferencia entre x86 y x64. ¿Algunas ideas?

SOLUCIÓN: Finalmente encontramos la solución. Resulta que nuestra asamblea fue de hecho una compilada de 32 bits. En Visual Studio, se utilizó el objetivo "Cualquier CPU", pero en la inspección de la .csproj subyacente, me encontré con el siguiente fragmento:

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

lo tanto, nuestro objetivo "Cualquier CPU" fue en realidad la construcción de un ensamblador x86! Aaargh. He rastreado esta línea en subversión, pero ya estaba allí en el primer checkin en 2006. Tal vez esto fue un error en alguna plantilla inicial del proyecto de base de datos?

De todos modos, gracias por su ayuda. Aceptaré la respuesta de Russ, ya que sospecho que muchos de los que experimenten los mismos problemas serán más ayudados por su respuesta.

Answer 1

No tiene que ver con el hecho de que es de 64 bits, debe modificar el DB para permitirlo. Prueba esto:

ALTER DATABASE YOURDATABASEHERE 
SET TRUSTWORTHY ON; 
GO 

si solos no funciona, puede probar estas opciones, así

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

Answer 2

Usted podría intentar cargar el ensamblado de archivo. No estoy seguro de si es posible implementar el ensamblado codificado en la versión de 32 bits en el servidor SQL de 64 bits utilizando la sintaxis de la cadena codificada.