First, why have you disabled "CLR strict security" and enabled "TRUSTWORTHY" if you have signed assemblies? Using signed assemblies means that you don't need to do either of those things. And in fact, there is really no reason to ever enable TRUSTWORTHY (please see: PLEASE, Please, please Stop Using Impersonation, TRUSTWORTHY, and Cross-DB Ownership Chaining).
Second, you are getting an "Access denied" error, which is a filesystem permissions issue, which is not specifically a SQLCLR security issue. Looking at the documentation for CREATE ASSEMBLY , it states (emphasis added):
The Windows login of the user that executes CREATE ASSEMBLY must have read permission on the share and the files being loaded in the statement.
The documentation for CREATE ASYMMETRIC KEY doesn't say anything useful about permissions, but the documentation for CREATE CERTIFICATE (which I assume is similar in approach to file system access) states:
The file is accessed in the security context of the SQL Server service account.
So, it's possible that either:
- the SQL Server service account has access to that folder and file, which is why CREATE ASYMMETRIC KEY works, yet your login does not have access to that folder or file, which is why CREATE ASSEMBLY fails,
- this is a kerberos double-hop issue since the file is on a share (i.e. remote system), in which case CREATE ASYMMETRIC KEY works because the SQL Server service account logs in directly to the server running SQL Server, but CREATE ASSEMBLY fails because you log on indirectly to that server (through a SQL client tool) and thus your credentials are not trusted by that remote server.
For #1, check permissions on the file. For testing, make sure that the folder and file assign read and execute to "Everyone". If this works, it's a simple permissions issue.
For #2, copy the file to the server running SQL Server (so that it is a local file) and see if that works. If it does, then you need to enable delegation, which takes some setup to do, so you might consider using BinaryFormatter (an open source utility I wrote) to turn the DLL into its string representation so that you can include it inline in the CREATE ASSEMBLY statement and skip the file system entirely (which is the better way to go in the first place). AND, if this is a Microsoft supplied DLL, then it is likely that they signed it with a certificate, in which case you can import the certificate instead of the asymmetric key. I am almost done with a blog post in which I will share a script that provides the CREATE CERTIFICATE statement with the binary literal representation of the certificate used to sign most (if not all) .NET Framework 4.x libraries, which might work for you as well. That should be published next week, hopefully.
Take care, Solomon..