This new change, “Trusted Assemblies” (which will be covered starting in Part 4), is entirely unnecessary due to existing functionality being able to handle all of the various scenarios. In order to alleviate some of the (perceived) hardship and complication of “clr strict security”, a second change was introduced in RC1 (released on July 17th). By itself it might even be considered amazingly bad, but an even newer feature was introduced that makes this one merely “bad”. Unfortunately, this is not a happy / fun / positive change it is a rather annoying, security-related change. SQL Server 2017 happens to come with the first change to SQLCLR since SQL Server 2012: a server-level configuration option named “clr strict security” (which we will cover in this post and the next two). Unfortunately, not all changes fit into this category. Some amazingly good changes are: Linux as a platform (see my editorial on SQL Server Central about it: Why I am Excited about SQL Server on Linux), Adaptive Query Processing, Resumable online index rebuild, some new DMVs, some new built-in string functions, etc.
RTM) and there are some impressive changes, with some being impressively good, and some being impressively bad. SQL Server 2017 is soon to be officially released (i.e. Which way you set this is up to your discretion.The Good, the Bad, and the Ugle̅e̅ (need to avoid copyright infringement -) ) We have it disabled to retain the flexibility of renaming the SQLCLR wrappers and selectively including only the objects we need.
This controls whether the publicly visible members in the assembly are automatically scripted into the output. The Generate Sql Script property I mentioned is in a similar state of documentation. Also, if there's a reference to an object in the assembly and this property is set to False, the project will fail to build. If the project doesn't include these objects in the model, there's no way they'll be scripted in the output. This property is poorly documented, but from my understanding, enabling it will expose the objects within the assembly to the database model so they can be used in the SQLCLR wrappers (i.e., CREATE.
The Model Aware property needs to be set to True. when I commented, I only mentioned what our settings are without understanding them I'm not the project lead for our migration to Database Projects, so I wasn't familiar with the minutiae of this stuff. I played around a bit to figure out what these settings do.
0 kommentar(er)
