CLR assembly will not load in 64 bit SQL Server 2005

Question

We use an assembly with some user defined functions in our installation of SQL Server 2005 (32 bit). We deploy this to production with a script like this:

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

We have never experienced any problems with these functions. Now, when we tried to upgrade one of our servers to x64, we got errors when calling any of the functions. Sample 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-

The error mentions the permission sets EXTERNAL_ACCESS AND UNSAFE whereas we use the level SAFE.

The .dll file is build with target platform set to 'Any CPU' and we get the same results when we try to load the dll from file instead of the varbinary syntax. We already tried the suggestions in http://support.microsoft.com/kb/918040

We have tried the exact same procedure on a 32 bit machine and everything just worked. It must be a difference between x86 and x64. Any ideas?

SOLUTION: We finally found the solution. It turns out that our assembly was indeed a 32 bit compiled one. In Visual Studio, we used the target "Any CPU", but on inspecting the underlying .csproj, I found the following snippet:

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

So our "Any CPU" target was actually building an x86 assembly! Aaargh. I have traced back this line in subversion, but it was already there at first checkin in 2006. Maybe this was a bug in some early template of the database project?

Anyway, thanks for your help. I will accept Russ's answer, as I suspect that many who experience the same problems will be helped most by his answer.

Answer 1

It doesn't have to do with the fact that it is 64 bit, you need to alter the DB to allow it. Try this:

ALTER DATABASE YOURDATABASEHERE
SET TRUSTWORTHY ON;
GO

if that alone doesn't work, you can try these options as well

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

Answer 2

You could try to load the assembly from file. I am not sure if it is possible to deploy assembly encoded on 32bit version to 64bit SQL Server using encoded string syntax.