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