11

I want to create SQLCLR based stored procedures for SQL Server. As you know I can build a dll against multiple versions of .NET framework. I can't find a reference that describe which version of SQL Server supports which version of .NET framework. Can anyone help to point me the right direction?

Just a learner
  • 21,448
  • 45
  • 133
  • 206
  • 1
    [This article](https://blogs.msdn.microsoft.com/dohollan/2010/07/08/sql-server-2008-r2-sqlclr-net-framework-version/) will probably answer your question and more. – dotNET Dec 13 '16 at 05:22
  • 1
    @dotNET That article can be misleading if one is not aware of both the difference and relationship between the CLR (and its versions) and the .NET Framework (and its versions). I will post an answer to be very clear about versions. – Solomon Rutzky Dec 13 '16 at 05:56

1 Answers1

33

To be clear, a single version of the CLR typically has multiple versions of the .NET Framework that it works with. A single version of the .NET Framework, however, only works with one specific version of the CLR. For example, CLR version 2.0 works with .NET Framework versions 2.0, 3.0, and 3.5, while CLR version 4.0 works with all of the 4.x versions of the .NET Framework (i.e. 4.0, 4.5[.x], 4.6[.x], 4.7[.x], etc). To see the chart of CLR version to Framework version relationships, see the MSDN page for .NET Framework Versions and Dependencies.

With regards to SQLCLR code, SQL Server only works with a single version of the CLR, and the specific version depends upon the version of SQL Server. SQL Server 2005, 2008, and 2008 R2 work only with CLR version 2. Since CLR version 2 only works with .NET Framework versions 2.0, 3.0, and 3.5, this means that SQL Server 2005, 2008, and 2008 R2 only work with .NET Framework versions 2.0, 3.0, and 3.5.

Of course, SQL Server 2005's CLR Integration feature (the initial version of it) was built around .NET Framework version 2.0 (as that is what was available at the time), so there are a couple of newer libraries in .NET Framework versions 3.0 and 3.5 that don't work in SQL Server 2005 without manually importing them (i.e. System.Core and System.Xml.Linq). Along those same lines, SQL Server 2012, 2014, 2016, 2017, and 2019 are statically linked to CLR version 4, which works with .NET Framework versions 4.0, 4.5[.x], 4.6[.x], and 4.7[.x].

If it makes it easier to understand, the info noted above, in chart form, is:

SQL Server version      |   CLR version   |   .NET Framework version(s)
------------------------|-----------------|----------------------------
2005                    |   2.0           |   2.0, 3.0 **, and 3.5 **
                        |                 | ** To use any functionality within
                        |                 |    System.Core or System.Xml.Linq
                        |                 |    libraries, they must be imported
                        |                 |    manually as UNSAFE.
------------------------|-----------------|----------------------------
2008 and 2008 R2        |   2.0           |   2.0, 3.0, and 3.5
------------------------|-----------------|----------------------------
2012, 2014, 2016, 2017, |   4.0           |   4.0+
and 2019, (and should   |                 |
also be Azure SQL DB    |                 |
Managed Instance)       |                 |
------------------------|-----------------|----------------------------

With regards to the information returned from both System.Environment.Version (in .NET code) and SELECT [value] FROM sys.dm_clr_properties WHERE [name] = N'version';, they are reporting the CLR version, not the .NET Framework version. So be careful not to confuse those two things reporting 2.0 or 4.0 as meaning you can only use Framework version 2.0 or 4.0.

And fortunately, due to backwards compatibility, code compiled against the CLR 2 Framework versions (2.0, 3.0, and 3.5) will run without needing to be recompiled in SQL Server 2012 and newer, even though they are on CLR version 4.

So, you generally cannot go wrong with using a Target Framework Version of 2.0, but you most certainly can use Framework versions beyond 2.0.

For a more in-depth look at developing SQLCLR code, check out the following article (and the series in general), which I wrote:

Stairway to SQLCLR Level 5: Development (Using .NET within SQL Server)

For more info on working with SQLCLR in general, please visit: SQLCLR Info

Solomon Rutzky
  • 41,664
  • 6
  • 112
  • 149
  • Thank you @srutzky. What do you mean by "SQL Server 2005 only included .NET Framework version 2.0"? – Just a learner Dec 13 '16 at 06:21
  • @OgrishMan Yeah, I wasn't sure how to best word that. I just updated to hopefully be clearer. Basically, there are two .NET Framework libraries that did not exist in .NET Framework 2.0, and so they couldn't have been included in the "Supported .NET Framework Libraries" list. But, they did exist when SQL Server 2008 was being coded, so they were able to add those 2 libraries to the "Supported" list. – Solomon Rutzky Dec 13 '16 at 06:39
  • Probably the query must be: SELECT value FROM sys.dm_clr_properties where name='version'; – Atanas Krachev Oct 09 '20 at 10:30
  • @AtanasKrachev You are correct. Thank you very much for pointing that out. Not sure what I was thinking 4 years ago, but clearly I didn't test it. I have now updated my answer with the correct query, plus I put the SQL Server version to .NET Framework version info into a chart so that it is hopefully easier / quicker to read / understand. – Solomon Rutzky Oct 15 '20 at 19:52