locked
SQL2014 Framework version? RRS feed

  • Question

  • Which version of the .NET framework should I target for a SQL2014 CLR extension?

    thanks

    Tuesday, April 28, 2015 9:08 PM

Answers

  • It really depends on what you have installed on your SQL Server machine. I haven't heard info one way or the other about 4.5, but by "4.0 compatible" and "2.0 compatible" I'm referring to the fact that only 2.0 and 4.0 shipped (and 1.0 and 1.1, but these are irrelevant to the question) with a new baseline of base class libraries. All others (3.0,  4.5) just upgraded the base 2.0/4.0 libraries in place, they didn't use an entirely new base. Look in C:\Windows\Microsoft.NET\Framework, for example, and see how many directories contain their own version of mscorlib.dll or System.dll. For example, Framework 3.0 only contains WCF,WPF,WWF and updates to the 2.0 base, it's not a "major" release as such.

    A place to see what post-4.0 versions are installed on a machine is the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs. On my machine, beside the SKU for 4.0, I also have 4.01, 4.02, 4.03, 4.5, 4.51, and 4.52. That's what I mean by "latest 4.0 compatible version" because with each new SKU, some of the basic libraries may be replaced *in-place* with newer versions. In this case, my latest "4.0-compatible version" would be 4.5.2.

    I'm more worried when you say "Service Bus assembly". It's not *your* assembly you need to worry about, it's the system assemblies that your assembly references. If you're referring to WCF, that's not supported in SQLCLR, but you can use "ASMX/Add New Web Reference" type endpoints to communicate with it. There's been a lot of discussion on this forum about this; do a few searches if you get error messages. The list of supported .NET system assemblies in SQLCLR is here: https://support.microsoft.com/en-us/kb/922672 Some system assemblies can be made to workaround by declaring your assembly as UNSAFE; some aren't even supported with that designation. I'd be very careful going the UNSAFE route.

    Hope this helps, Bob

    • Marked as answer by scott_m Wednesday, April 29, 2015 2:24 AM
    Tuesday, April 28, 2015 11:51 PM

All replies

  • SQL Server 2014 supports the "latest 4.0-compatible version", although most 2.0-compatible (except for those that use unsupported system CLR libraries) should work also via backward compat.

    Don't assume SQLCLR will honor parameter changes you might want to try and make to the sqlservr.exe.config file, or that it will run multiple CLR versions; in general it won't. You can see the version of CLR that's being loaded by looking for a message in the SQL Server log.

    You should target the "latest 4.0-compatible version" installed on the machine where SQL Server runs (i.e. try and sync up your dev CLR environment with the server environment).

    Or are you looking for something even more specific or specific unsupported system CLR? (I'd not recommend using unsupported system CLR from a supportability point of view)

    Hope this helps, Bob

     
    Tuesday, April 28, 2015 9:35 PM
  • Ah, so 4.5 framework wouldn't work?  It needs to be 4.0 then?

    This is a service bus assembly which uses pure msil.

    scott

    SQL2014

    Windows2012

    Tuesday, April 28, 2015 9:39 PM
  • It really depends on what you have installed on your SQL Server machine. I haven't heard info one way or the other about 4.5, but by "4.0 compatible" and "2.0 compatible" I'm referring to the fact that only 2.0 and 4.0 shipped (and 1.0 and 1.1, but these are irrelevant to the question) with a new baseline of base class libraries. All others (3.0,  4.5) just upgraded the base 2.0/4.0 libraries in place, they didn't use an entirely new base. Look in C:\Windows\Microsoft.NET\Framework, for example, and see how many directories contain their own version of mscorlib.dll or System.dll. For example, Framework 3.0 only contains WCF,WPF,WWF and updates to the 2.0 base, it's not a "major" release as such.

    A place to see what post-4.0 versions are installed on a machine is the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SKUs. On my machine, beside the SKU for 4.0, I also have 4.01, 4.02, 4.03, 4.5, 4.51, and 4.52. That's what I mean by "latest 4.0 compatible version" because with each new SKU, some of the basic libraries may be replaced *in-place* with newer versions. In this case, my latest "4.0-compatible version" would be 4.5.2.

    I'm more worried when you say "Service Bus assembly". It's not *your* assembly you need to worry about, it's the system assemblies that your assembly references. If you're referring to WCF, that's not supported in SQLCLR, but you can use "ASMX/Add New Web Reference" type endpoints to communicate with it. There's been a lot of discussion on this forum about this; do a few searches if you get error messages. The list of supported .NET system assemblies in SQLCLR is here: https://support.microsoft.com/en-us/kb/922672 Some system assemblies can be made to workaround by declaring your assembly as UNSAFE; some aren't even supported with that designation. I'd be very careful going the UNSAFE route.

    Hope this helps, Bob

    • Marked as answer by scott_m Wednesday, April 29, 2015 2:24 AM
    Tuesday, April 28, 2015 11:51 PM
  • I learned the hard way about System.ServiceModel dependencies not working.  That led me to fork RabbitMQ and remove the dependency :)     I just needed to know what framework to target when building RabbitMQ.  Guess whatever the latest 4.x framework is on the SQL server, I will target.

    Thanks for the explanation.

    scott


    • Edited by scott_m Wednesday, April 29, 2015 2:24 AM
    Wednesday, April 29, 2015 2:23 AM
  • Good choice (on removing the dependency on System.ServiceModel). I think Niels Berglund posted something recently on this forum about removing that dependency from RabbitMQ. Either you or he ought to check that branch in. ;-)

    It's not necessarily that big of a deal, the *exact* version of 4.x, unless you're using UNSAFE/unsupported system assemblies. If you're not (using them) it will likely work just fine as long as its a lower minor version. If you are using them, you'll get errors at CREATE ASSEMBLY-time.

    Cheers, Bob 

    Wednesday, April 29, 2015 2:54 AM