4

So, I created a PE32+ DLL, in an attempt to load it into SQL Server,

$ file example_dll.dll 
example_dll.dll: PE32+ executable (DLL) (console) x86-64, for MS Windows

but when I try to compile it as an assembly, with CREATE ASSEMBLY [ok] AUTHORIZATION [dbo] ... WITH PERMISSION_SET = UNSAFE; I get,

Msg 6544, Level 16, State 1, Server x230, Line 1
CREATE ASSEMBLY for assembly 'ok' failed because assembly 'ok' is malformed or not a pure .NET assembly. 
Unverifiable PE Header/native stub.

It as come to my attention that what Micrsoft calls CLR "safe" may just mean, .NET's C++. I know that C# is the prefered method of extending SQL Server, but regardless does Microsoft permit loading shared objects or DLL into the server at all? Can you extend SQL Server with "native code"?

Improve this question
1

1 Answer 1

Reset to default
4

SQLCLR only allows for managed code / pure-MSIL Assemblies. So .NET Visual C++ might work, and I think I have seen one example of it.

You can load / call unmanaged C++ DLLs in an UNSAFE C# / VB.NET Assembly, but that can be riskier than using "unsafe" .NET functionality.

In theory, any .NET language should work IF it produces a pure-MSIL Assembly, but I have yet to see working examples of this. I have seen an example of Visual C++, and I have seen an example of someone coding actual MSIL (on Stack Overflow), though I'm still doubtful as to the supposed benefit of that.

Folks have tried F#, but can't doing that as SAFE since it requires another library for F#:

F# with sqlclr in a reasonably safe way and scripted assembly

As to the updated question, which now also asks about the Extended Stored Procedure (xp) API, that should be deprecated and frowned-upon.

Improve this answer
3
  • I have not actually tried it. But I have been working in the .NET world for many years. In the .NET universe, C#, VB.NET, C++, F#, etc. all compile to an assembly that is MSIL. Once it is MSIL, the consuming code (either some app you are building, or SQL, or whatever) is blind to the original authoring language.
    – Jonesome Reinstate Monica
    Dec 17, 2017 at 22:57
  • @samsmith I wouldn't say completely blind since in the F# case, there is a language-dependency that requires the F#.Core Assembly, which seems to require UNSAFE, which means that it cannot load if SQL Server is running on Linux (or any other environment that only allows for SAFE assemblies, such as Azure SQL Database for the 18 months or so that it allowed SQLCLR ;-).
    – Solomon Rutzky
    Dec 17, 2017 at 23:49
  • Each language in .NET has a helper assembly. It is possible that some of those helpers (F#, perhaps others) have attributes that are incompatible with being running inside SQL Server. That said, I would expect the number of situations that this applies to are very small.
    – Jonesome Reinstate Monica
    Dec 18, 2017 at 4:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.