Is it possible to create an asymmetric key for a .NET framework assembly in SQL Server 2014?

Question

I am developping an SQL Server Database Project in Visual Studio which is in fact a User Defined Function. In this project, I included Json.NET as a reference (using NuGet).

Answer 1

I managed to do this on SQL Server 2014 (version 11.0.6248.0) for the .Net Framework 4 Systen.Drawing.dll, using the following script

USE MASTER
GO

CREATE 
    ASYMMETRIC KEY SystemDrawingKey 
    FROM EXECUTABLE FILE = N'C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Drawing.dll'   

CREATE 
    LOGIN SystemDrawingKeyLogin 
    FROM ASYMMETRIC KEY SystemDrawingKey   

GRANT UNSAFE ASSEMBLY TO SystemDrawingKeyLogin

USE MY_DATABASE
GO 

CREATE ASSEMBLY [SystemDrawing]
FROM N'C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Drawing.dll' WITH PERMISSION_SET = UNSAFE
GO 

SQL Server accepts this assembly, but gives a warning:

Warning: The Microsoft .NET Framework assembly 'system.drawing, version=4.0.0.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a, processorarchitecture=msil.' you are registering is not fully tested in the SQL Server hosted environment and is not supported. In the future, if you upgrade or service this assembly or the .NET Framework, your CLR integration routine may stop working. Please refer SQL Server Books Online for more details.

To verify that the thustworthy setting is off, I ran the following query from A warning about the TRUSTWORTHY database option:

SELECT name, is_trustworthy_on
FROM sys.databases
WHERE name <> 'msdb'
AND is_trustworthy_on = 1

Which gave no results. Of course, now I have WITH PERMISSION_SET = UNSAFE, but that seems less problematic.

System.Drawning.dll is a dependency I need for a third party assembly. I am pretty sure the methods I call do not invoke anything in System.Drawing, so for now, I keep things this way.

Also, I got an error when creating my own custom assemby. I have lost the exact error, but mentioned Synchonization and it referenced System.Diagnostics, which helped me find a call to Debug.WriteLine. After remvoing that, the assembly could be created and all worked fine.