Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
OklahomaDave
Starting Member
1 Post |
 Posted - 2014-04-08 : 22:35:01
|
| Hi all. Quick question as I fear my mind may be losing its grip on reality, thought I'd check here and see if I could straighten something out. I've always understood that the semantics of CREATE ASSEMBLY...PERMISSION_SET = UNSAFE was to allow an assembly to talk to unmanaged code. I've used this understanding to do some fairly tricky assembly registration and its worked just fine....from SQL 2005 through SQL 2008R2...until SQL2012.Now, I have this assembly, and when I register it (accidentally) without PERMISSION_SET = unsafe, I get all kinds of "CLR Verifier" Errors about unmanaged pointers, unverifiable types, etc. and that makes sense - the normal fix is to just add "PERMISSION_SET = UNSAFE" and the assembly registers. But with this particular assembly, adding the UNSAFE tag doesn't help. It *still* comes across with "unmanaged pointer" and similar messages.I thought that UNSAFE was essentially the equivalent of "registering an assembly with your eyes wide open," as it were, in terms of calling unmanaged code. Seems to me that kind of verification shouldn't even be firing - yet it is, when it didn't before. Where is my understanding going goofy? Have I always understood incorrectly, or has something changed in the SQL2012 CLR Verification process/rules?If someone could clear up the haze in my foggy head, I'd be most appreciative.Thanks,OklahomaDave |
|
|
|
|
|
|
|
SQLCLR and "UNSAFE" permission semantics