> "which probably doesn't matter at the end of the day because almost no DBA would ever let you use it in production."
Where I work, we have a DBA and use SQL CLR in production. In fact I'm in the process of writing a SQL CLR user defined function today. It's interesting that Microsoft have dropped support for them in Azure, but they're still supported in SQL Server 2016. Furthermore, starting from Visual Studio 2013 efforts were made to make them easier to deploy direct from Visual Studio, so clearly some people in Microsoft think they're worth supporting.
I'd say as long as you have a sane database structure where you don't try to do all your processing in a single database instance, SQL CLRs are fine. For example, use them in databases that handle scheduled processes rather than in ones that can't have any downtime and you it'll be easier to redeploy them without much ceremony.
And if your answer is RTFM then you've probably not used SQL Server before, or were fortunate to have always work on a perfectly configured instance, because a lot of things (say, debugging) often don't work on a brand new install on a brand new windows box.
There are tons of things like this where people have been crying for help from Microsoft for years, but the SQL Server team clearly does not give one fuck about their users problems.
I've not needed to sign a SQLCLR DLL, all the SQLCLR code I've written has been using SAFE assemblies.
That being said, I don't mind helping out. Here are the relevant notes I made when following the "Developer's Guide to SQL Server CLR Integration" on Pluralsight:
"To configure assembly signing, open project properties, SQLCLR, scroll down to find and select the 'Signing...' button, check the 'Sign the assembly' checkbox, choose or create a 'Strong name key file' (if select <New...>, set key file name e.g. CLRLogReader, and set a password, OK to finish), OK to finish, then close project properties tab."
From the troubleshooting section of the same course...
"If you want to deploy an assembly that uses EXTERNAL_ACCESS (or UNSAFE) permissions instead of SAFE permissions, you need to perform some extra steps in order to grant those permissions to the login deploying the assembly. There are a few different ways to set those permissions (including enabling the EXTERNAL ACCESS ASSEMBLY permission for the DBO and switching the TRUSTWORTHY property on, or signing the assembly with a certificate), but the recommended method is to sign the assembly with an asymmetric key (recommended because it is both easy to do and secure). In VS, load properties for SQL Database project, SQLCLR tab, scroll down to find and click on Signing... button. Check the 'Sign the assembly' option, create/select strong key file, OK. Build project, make sure this process completes without errors. Then in SSMS will need to set up a user that can use the key that was used in the build process. Example:
USE master;
CREATE ASYMMETRIC KEY CLRLog
FROM EXECUTABLE FILE =
'Path to SQL CLR DLL' --note this DLL was the one created in the build process carried out in VS
CREATE LOGIN CLRLogin FROM ASYMMETRIC KEY CLRLog
GRANT EXTERNAL ACCESS ASSEMBLY TO CLRLogin
Note that you only have to configure this assembly signing once, subsequent deployments will reuse the key and login we configured to deploy the assembly, so deployment then becomes as straightforward as deployment of SAFE assemblies."
Where I work, we have a DBA and use SQL CLR in production. In fact I'm in the process of writing a SQL CLR user defined function today. It's interesting that Microsoft have dropped support for them in Azure, but they're still supported in SQL Server 2016. Furthermore, starting from Visual Studio 2013 efforts were made to make them easier to deploy direct from Visual Studio, so clearly some people in Microsoft think they're worth supporting.
I'd say as long as you have a sane database structure where you don't try to do all your processing in a single database instance, SQL CLRs are fine. For example, use them in databases that handle scheduled processes rather than in ones that can't have any downtime and you it'll be easier to redeploy them without much ceremony.