Support CLR Stored Procedures
Thanks for your feedback. We now have the next generation of Azure SQL DB in public preview in the US and GA in Europe.
Specifically it supports CLR.
Details here http://azure.microsoft.com/blog/2014/12/11/preview-available-for-next-generation-of-azure-sql-database/ and https://msdn.microsoft.com/library/ms189524.aspx
Rich C commented
If CLR isn't coming back, please could you consider adding regex? The string concat is a good start, but a couple of basic regex functions (match, split, replace) would make azure hosting viable again.
Christian DeBry commented
Please reopen. CLR functionality was removed in April 2016.
George Walters commented
This needs to be changed away from "Completed" since it's been removed.
Hi bdean_zap, unfortunately CLR is being discontinued due to security threats...
Received this email early April 2016:
In an effort to protect the security of our customers, we have proactively suspended the use of user-defined SQL CLR in Azure SQL Database.
My name is Joachim Hammer, and I’m a Principal Security Program Manager for the Azure SQL Database service.
I’m notifying you of an important change we’re making to SQL Database. If you’re not using SQL Common Language Runtime (SQL CLR) in SQL Database or have no plans for using it, no further action is needed on your part.
We’ve determined that there is a security risk with user-defined SQL CLR in SQL Database. There have been no known exploits to date. In an effort to help protect the security of our customers, we have proactively suspended the use of user-defined SQL CLR. This means that user-defined SQL CLR will no longer work. We’ll update you within six months with a timeline for bringing back SQL CLR.
Your existing SQL CLR assemblies hosted in SQL Database will continue to work until April 15, 2016. If you require your existing SQL CLR assemblies, please contact me.
We’re committed to minimizing the impact of this change on your applications and business.
Thanks for your understanding,
I'm using V12 and it doesn't seem to support CLR. Is there something I'm missing?
If the new Azure CLR feature only supports safe assemblies, does that mean any CLR aggregates that require Format.UserDefined (e.g. binary serializers) for purposes like VerticalConcatDistinct will not be supported? :o
Long waiting CLR feature is coming, but only support safe assemblies, so disappointed
David Bowler commented
Awesome news!! Terry's child will be so proud! We can now look at migrating.
Great news! Thanks for the update. This means we can revisit the migration to Azure again this year.
I use CLR for our own aggregate functions like concatenate() and concatenatedistinct(), as well as Regex functions and Levenstein distance.
Without CLR we would have to rewrite a lot of our code. It's like going back to SQL 2000.
So we are not porting our solution until we have CLR.
To prove how important this is, we've just christened our child "CLR"
Kevin Christensen commented
We cannot consider Azure Sql until CLR is supported.
Jimi J commented
CLR Triggers and SPs are very critical for the overall performance of our application. Hence, we can't move to SQL azure.
Appreciate the update, we're watching for its release closely... :)
CLR is the only reason for us at this point to stick to on-premises. I wish Microsoft would consider adding CLR to Azure.
Mike Hebert commented
Not just regex - I also use it for converting datetimes between different timezones.
Henri Koppen commented
I understand the CLR is complex in a multi-tenant environment, and with worker roles it's fairly easy to work around, but I use CLR a lot (template replacements, regex) so i'd love to have it!
The only way to get real regex functionality. In fact why don't you just add in one module as a clr that has a regex match function since that's the main reason most people that I talk with use it.
Seems noone from SQL Azure want to talk about the adding back of CLR, maybe they have big issue to do that, and they haven't figured it out how to do it.
We can not migrate to SQL Azure without CLR support.