SQLProvider icon indicating copy to clipboard operation
SQLProvider copied to clipboard

Issue when registering into SQL server a SQL CLR assembly referencing SQLProvider

Open francotiveron opened this issue 6 years ago • 4 comments

Description

I have a F# DLL (.NET Framework 4.5.1, F# 4.1, FSharp.Core 4.4.3.0). The only added reference is to FSharp.Data.SqlProvider 1.1.41.

The code is in on file only

module DB

open FSharp.Data.Sql

[<Literal>]
let private dbVendor = Common.DatabaseProviderTypes.MSSQLSERVER

Build goes without errors

Repro steps

  1. Step A

Import the built dll in SQL server as assembly CREATE ASSEMBLY [Library2] FROM 'path\Library2.dll' WITH PERMISSION_SET = UNSAFE

Expected behavior

Assembly correctly imported

Actual behavior

Operation fails with error Assembly 'Library2' references assembly 'fsharp.core, version=4.3.1.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a.', which is not present in the current database. SQL Server attempted to locate and automatically load the referenced assembly from the same location where referring assembly came from, but that operation has failed (reason: version, culture or public key mismatch). Please load the referenced assembly into the current database and retry your request

  1. Step A

comment the last two rows in the code

//[<Literal>]
//let private dbVendor = Common.DatabaseProviderTypes.MSSQLSERVER

Expected behavior

No difference from 1.

Actual behavior

Operation succeeds, the assembly is correctly created in SQL server

Known workarounds

If I downgrade the project to F# 3.1 (FSharp.Core 4.3.1.0), then no error in both cases

Related information

  • Used database SQL Server 14.0.1000
  • Operating system Windows 10 Pro
  • .NET Runtime, CoreCLR or Mono Version 4.5.1

francotiveron avatar Apr 27 '18 04:04 francotiveron

I'm not familiar with importing assemblies into Sql Server, but the way conflicting dependency versions are handled at the dll level is usually through a binding redirect in Your_Library.dll.config.

Paket for example will generate these automatically, instructing the runtime to use the latest version of FSharp.Core:

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.4.3.0" newVersion="4.4.3.0" />
      </dependentAssembly>
    </assemblyBinding>

I don't know if SQL Server will respect these redirects with CREATE ASSEMBLY, but just in case, can you create such a file in the same folder as your library (if it doesn't already exist) and add a redirect like the above?

If it doesn't respect them, then I think that's a bug/issue to submit to the MSSQL team. Nothing about the above mechanisms is related to type providers or SqlProvider in particular.

piaste avatar Apr 27 '18 08:04 piaste

Binding redirection was there since the beginning. As you say my suspect is also that the issue is on the SQL Server side, perhaps the CREATE ASSEMBLY ignores the .config and simply parses the assembly, where the reference is to the build-time version. I'll raise the issue on the MSSQL team as you say

francotiveron avatar Apr 27 '18 22:04 francotiveron

@francotiveron Did you ever find a solution to that? I'm having the same issue trying to add FSharp.Data to SQL Server via CREATE ASSEMBLY

Msg 6503, Level 16, State 12, Line 92
Assembly 'fsharp.core, version=4.3.1.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a.' was not found in the SQL catalog.

augustoproiete avatar Nov 01 '18 05:11 augustoproiete

No, I didn't find a solution, I downgraded version and used F# 3.1

francotiveron avatar Nov 01 '18 20:11 francotiveron