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.

 All Forums
 SQL Server 2012 Forums
 SQL Server Administration (2012)
 SQLCLR and "UNSAFE" permission semantics

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
   

- Advertisement -