"Trusted Assemblies", introduced in RC1 of SQL Server 2017, seems like a reasonable fix for one, if not two, problems resulting from the new "CLR strict security" setting. But are there any problems with it? And even if not (don't worry, there are), might there be a better approach? Perhaps something simple that was overlooked?
Welcome back, everyone. In the previous post in this series, I explained how to work within the new SQLCLR security restriction in SQL Server 2017 (i.e. that all Assemblies need to be signed and have a corresponding Login that has been granted the UNSAFE ASSEMBLY permission). That approach is 22 steps, but they are all… Continue reading SQLCLR vs. SQL Server 2017, Part 3: “CLR strict security” – Solution 2
(last updated: 2019-03-31 @ 16:30 EST / 2019-03-31 @ 20:30 UTC ) As mentioned in Part 1 of this "SQLCLR vs. SQL Server 2017" series, the new clr strict security server-level configuration option requires that in order to create any Assembly, even a SAFE one, it must be signed (by a Certificate or Strong Name… Continue reading SQLCLR vs. SQL Server 2017, Part 2: “CLR strict security” – Solution 1
The Good, the Bad, and the Ugle̅e̅ (need to avoid copyright infringement ;-) ) (last updated: 2018-10-22 @ 10:40 EDT / 2018-10-22 @ 14:40 UTC ) SQL Server 2017 is soon to be officially released (i.e. RTM) and there are some impressive changes, with some being impressively good, and some being impressively bad. The Good… Continue reading SQLCLR vs. SQL Server 2017, Part 1: “CLR strict security” – The Problem
