L'assembly CLR non verrà caricato in SQL Server 2005 a 64 bit

Question

Usiamo un assembly con alcune funzioni definite dall'utente nella nostra installazione di SQL Server 2005 (32 bit). Lo distribuiamo alla produzione con uno script come questo:

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 

Non abbiamo mai riscontrato problemi con queste funzioni. Ora, quando abbiamo provato ad aggiornare uno dei nostri server a x64, abbiamo ricevuto degli errori quando chiamavamo una delle funzioni. Esempio stack trace:

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-

L'errore cita il permesso imposta EXTERNAL_ACCESS E UNSAFE, mentre usiamo il livello SAFE.

Il file .dll è stato creato con la piattaforma di destinazione impostata su "Qualsiasi CPU" e otteniamo gli stessi risultati quando proviamo a caricare la DLL dal file invece della sintassi varbinary. Abbiamo già provato i suggerimenti in http://support.microsoft.com/kb/918040

Abbiamo provato la stessa identica procedura su una macchina a 32 bit e tutto ha funzionato. Deve essere una differenza tra x86 e x64. Qualche idea?

SOLUZIONE: Abbiamo finalmente trovato la soluzione. Si scopre che il nostro assembly è stato effettivamente compilato a 32 bit. In Visual Studio, abbiamo usato il target "Qualsiasi CPU", ma su ispezione del csproj sottostante, ho trovato il seguente frammento:

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

Quindi il nostro obiettivo "Qualsiasi CPU" è stata in realtà la costruzione di un assembly x86! Aaargh. Ho risalito questa linea in sovversione, ma era già lì al primo checkin nel 2006. Forse questo era un bug in alcuni dei primi modelli del progetto di database?

In ogni caso, grazie per il vostro aiuto. Accetterò la risposta di Russ, poiché sospetto che molti di coloro che sperimentano gli stessi problemi saranno maggiormente aiutati dalla sua risposta.

Answer 1

Non ha a che fare con il fatto che è 64 bit, è necessario modificare il DB per consentirlo. Prova questo:

ALTER DATABASE YOURDATABASEHERE 
SET TRUSTWORTHY ON; 
GO 

se questo da solo non funziona, si può provare a tali opzioni e

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

Answer 2

Si potrebbe provare a caricare l'assembly dal file. Non sono sicuro se sia possibile distribuire l'assembly codificato su versione a 32 bit su SQL Server a 64 bit utilizzando la sintassi della stringa codificata.