L'assembly CLR ne se charge pas dans SQL Server 2005 64 bits

Question

Nous utilisons un assembly avec certaines fonctions définies par l'utilisateur dans notre installation de SQL Server 2005 (32 bits). Nous déployons cela en production avec un script comme celui-ci:

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 

Nous n'avons jamais rencontré de problèmes avec ces fonctions. Maintenant, quand nous avons essayé de mettre à jour l'un de nos serveurs vers x64, nous avons eu des erreurs lors de l'appel de l'une des fonctions. trace de la pile échantillon:

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'erreur mentionne l'autorisation définit EXTERNAL_ACCESS ET UNSAFE alors que nous utilisons le niveau SAFE. Le fichier .dll est construit avec la plate-forme cible définie sur "Any CPU" et nous obtenons les mêmes résultats lorsque nous essayons de charger la DLL à partir du fichier au lieu de la syntaxe varbinary. Nous avons déjà essayé les suggestions dans http://support.microsoft.com/kb/918040

Nous avons essayé exactement la même procédure sur une machine 32 bits et tout a fonctionné. Ce doit être une différence entre x86 et x64. Des idées? SOLUTION: Nous avons finalement trouvé la solution. Il s'avère que notre assemblée était en fait une compilation 32 bits. Dans Visual Studio, nous avons utilisé la cible « Tout CPU », mais sur l'inspection de la .csproj sous-jacente, je trouve l'extrait suivant:

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

Donc, notre « Any CPU » cible était en fait la construction d'un ensemble x86! Aaargh. J'ai retrouvé cette ligne dans Subversion, mais il était déjà là au premier checkin en 2006. Peut-être que c'était un bug dans un des premiers modèles du projet de base de données?

Quoi qu'il en soit, merci pour votre aide. J'accepterai la réponse de Russ, car je soupçonne que beaucoup de ceux qui éprouvent les mêmes problèmes seront les plus aidés par sa réponse.

Answer 1

Cela n'a rien à voir avec le fait que c'est 64 bits, vous devez modifier le DB pour l'autoriser. Essayez ceci:

ALTER DATABASE YOURDATABASEHERE 
SET TRUSTWORTHY ON; 
GO 

si cela seul ne fonctionne pas, vous pouvez essayer ces options ainsi

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

Answer 2

Vous pouvez essayer de charger l'ensemble du fichier. Je ne suis pas sûr s'il est possible de déployer l'ensemble codé sur la version 32 bits à 64 bits SQL Server en utilisant la syntaxe de chaîne codée.