Loading assembly into SQL Server 2017 database

Question

I am trying to load a CLR assembly Split.dll into a SQL Server 2017 database:

CREATE ASSEMBLY Split FROM 'D:\SqlClr\split.dll' WITH Permission_set = SAFE GO

I've built this assembly using Visual Studio 2019. But I get this error:

Msg 10301, Level 16, State 1, Line 1
Assembly 'Split' references assembly 'netstandard, version=2.0.0.0, culture=neutral, publickeytoken=cc7b13ffcd2ddd51.', 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: 2 (The system cannot find the file specified.)). Please load the referenced assembly into the current database and retry your request.

I've tried to do the same with SQL Server 2014 and Visual Studio 2015. Actually I've used the same C# code to get DLL and the same SQL statement (showed above) to load it. In this case everything worked well.

I've read Sql Server CLR load assembly failed but when I was trying to loading netstandard.dll:

CREATE ASSEMBLY netstandard 
AUTHORIZATION dbo 
FROM 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\netstandard.dll' 
WITH Permission_set = SAFE
GO

I get this error:

Msg 6212, Level 16, State 1, Line 1
CREATE ASSEMBLY failed because method 'EnsureEventSourceIndexAvailable' on type 'System.Diagnostics.Tracing.EventCounterGroup' in safe assembly 'System.Diagnostics.Tracing' is storing to a static field. Storing to a static field is not allowed in safe assemblies.

Can anybody help me? Why did the same code work well in SQL Server 2014 and DLL built in Visual Studio 2015 and I've got a problem now (SQL Server 2017, Visual Studio 2019)? What is the way of fixing this problem?

Answer 1

Just for speedy clarification as I must have bounced off of this question a couple times in my own search for a solution. The answer is actually given in the comments above... I just didn't read the comments at first. The problem was that I had selected the wrong Framework. The .Net Standard Framework shows at the top of the list... the correct framework is way down the list so it is easily (at least for me) missed: