Cannot create assembly referencing system.core v3.5.0.0

  • Hi,

    We have developed a number of components implementing business logic in .Net 3.5 and using VS 2008. One of those components is a DLL implementing interpolation methods and it has a reference to System.core as it uses Linq. It is signed with a private key.

    I would like to be able to use this functionality from a UDF and\or stored procedure in SQL Server 2005. I have copied all the referenced assemblies in the same folder as the DLL on the server, including the System.core.dll. I tried to create the assembly using the following T-SQL statement:

    CREATE ASSEMBLY [AssemblyName]

    AUTHORIZATION [dbo]

    FROM 'path to assembly files'

    WITH PERMISSION_SET = SAFE

    This returns the following error:

    Warning: The Microsoft .Net frameworks assembly 'system.core, version=3.5.0.0, culture=neutral, publickeytoken=b77a5c561934e089, processorarchitecture=msil.' you are registering is not fully tested in SQL Server hosted environment.

    Msg 6218, Level 16, State 2, Line 1

    CREATE ASSEMBLY for assembly 'AssemblyName' failed because assembly 'System.Core' failed verification. Check if the referenced assemblies are up-to-date and trusted (for external_access or unsafe) to execute in the database. CLR Verifier error messages if any will follow this message

    [ : System.Diagnostics.Eventing.EventProvider::EtwRegister][mdToken=0x600003b][offset 0x0000003D][found Native Int][expected unmanaged pointer] Unexpected type on the stack.

    [ : System.Diagnostics.Eventing.EventProvider::EncodeObject][mdToken=0x6000046][offset 0x00000000] Unmanaged pointers are not a verifiable type.

    [ : System.Diagnostics.Eventing.EventProvider::WriteMessageEvent][mdToken=0x6000047][offset 0x0000003C][found ref 'System.String'] Expected numeric type on the stack.

    [ : System.Diagnostics.Eventing.EventProvider::WriteEvent][mdToken=0x6000049][offset 0x0000012E] Instruction cannot be verified.

    [ : System.Diagnostics.Eventing.EventProvider::WriteEvent][mdToken=0x6000049][offset 0x00000030] Instruction cannot be verified.

    [ : System.Diagnostics.Eventing.EventProvider::WriteEvent][mdToken=0x600004a][offset 0x0000005F][found ref 'System.String'] Expected numeric type on the stack.

    [ : System.Diagnostics.Eventing.EventProvider::WriteEvent][mdToken=0x600004b][offset 0x00000010][found unmanaged pointer][expected unmanaged pointer] Unexpected type on the stack.

    [ : System.Diagnostics.Eventing.EventProvider::WriteTransferEvent][mdToken=0x600004c][offset 0x0000007D] Instruction cannot be verified.

    [ : System.Diagnostics.Eventing.EventProvider::WriteTransferEvent][mdToken=0x600004c][offset 0x00000309][found Native Int][expected unmanaged pointer] Unexpected type on the stack.

    [ : System.Diagnostics.Eventing.EventProvider::WriteTransferEvent][mdToken=0x600004d][offset 0x0000001B][found unmanaged pointer][expected unmanaged pointer] Unexpected type on the stack.

    [ : System.Linq.Expressions.ExpressionCompiler::GenerateLambda][mdToken=0x6000374][offset 0x00000046] Unable to resolve token.

    [ : System.Security.C...

    The only resolution that was suggested was to use PERMISSION_SET = UNSAFE and set the database to TRUSTWORTHY which I don't want to do.

    Is there any other solution to this?

    Many thanks in advance.

    Laurence

  • Abstract the logic that you want to use inside SQL Server to a new assembly and restrict it to the approved assembly list only. That is the only alternative to registering the unapproved .NET DLL's as UNSAFE in the Database.

    Jonathan Kehayias | Principal Consultant | MCM: SQL Server 2008
    My Blog | Twitter | MVP Profile
    Training | Consulting | Become a SQLskills Insider
    Troubleshooting SQL Server: A Guide for Accidental DBAs[/url]

  • I had thought that in SQL Server 2005 the CLR was only .NET 2.0 compliant so that 3.5 assemblies will not work, thus no Linq availability. I could be wrong.

  • I know that it's possible to use .NET 3.0 assemblies (to call a WCF service for example) but as far as I know they haven't been tested so the same would probably go for .NET 3.5. Perhaps you could re-write the linq stuff to not use linq (unless there is way too much of it).

Viewing 4 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic. Login to reply