How do you declare objects in the master database

Question

I am trying to register our CLR assembly as an unsafe assembly without having to make the database trustworthy.  Since making the database is_trustworthy_on = 1 is not a best practice, and would cause some of our customers (and our development process)
a little bit of grief.
I have read a ton about it but am still having trouble.
The reason the assembly is 'Unsafe' is because it is calling the TimeZoneInfo class to convert between timezones, since we are not yet on UTC dates.  We plan to in the future but that's a big project.
We are also not using the 'SQLCLR' but rather have written our own class library and just have a project reference to it, which works just the same, but we have found to be better for the C# programmers.
I am playing with signing the assembly using an SNK file and have figured out what I need to do, including 1) creating a master key, 2) creating an asymmetric key using the same SNK file that signed the assembly, 3) creating a login for the asymmetric key,
and 4) granting unsafe assembly to the login.
When I do all that with straight SQL, it actually works!  But I am having trouble fitting this into our SSDT world.
Should I create a separate SSDT project for items #1 through #4 above, and reference it, and check 'Include composite objects' in our publishing options?  As stated in this blog post though, I'm terrified of messing up the master database, and I'm not
excited about the overhead of another project, a 2nd dacpac, etc.
http://blogs.msdn.com/b/ssdt/archive/2012/06/26/composite-projects-and-schema-compare.aspx
Since we do use a common set of deployment options in a deployment tool we wrote, which does set the 'block on data loss' to false, and the 'drop objects not in source' to true, b/c we drop tables all the time during the course of refactoring, etc. 
I don't want to drop anything in master though, and I don't want to have to publish it separately if we didn't have to. 
I suppose I could just have some dynamic SQL in a pre-deployment script that takes care of the master database, but I was trying to do it the 'right' way, in a declarative style, but struggling.
So, in short, what's the recommended approach for getting an 'unsafe' CLR assembly into an SSDT project?
The error that started all this was:
CREATE ASSEMBLY for assembly *** failed because assembly *** is not authorized for PERMISSION_SET = UNSAFE. 
The assembly is authorized when either of the following is true:
the database owner (DBO) has UNSAFE ASSEMBLY permission and the database has the TRUSTWORTHY database property on;
or
the assembly is signed with a certificate or an asymmetric key that has a corresponding login with UNSAFE ASSEMBLY permission.
Also, would a certificate be better than an asymmetric key?  I'm not entirely sure of the difference just yet to be honest.
Thanks,
Ryan

Answer 1

After much fighting with this, figured something out as a workaround, and thought I'd share it.
First, I'm pretty certain the SSDT declarative way for these master objects just doesn't work yet.
My workaround was to make a pre-deployment script (that runs when we create new databases, as well as for the current release), that takes care of the security items needed to support a signed CLR assembly with unsafe permissions.
One issue we were running into was when it came to creating the asymmetric key, there are 4 ways to do so, and we didn't want to depend on a hard-coded/absolute file path.  The 4 ways are "From file", "from external file", "from
assembly", or "from provider".  I still don't 100% understand the from provider way, but ultimately we are actually using the from assembly way, with a little trick/hack I did that allows us to not have to use the 'from file' way and to
reference a hard-coded path on someone's C:\ drive.  I really really didn't want to do that b/c we create local dev databases all the time and not everyone has the same paths setup.  Also, our databases are deployed on our servers as well as remote-hosted-customer
servers, and up until now, the database release has not needed file system access.  Even the CLR itself is created using assembly_bits, which is awesome.
So I thought of something...
What if I had a simple/temporary assembly, which I create from assembly_bits, use to import the public key from, through the create asymmetric key from assembly command, and then drop as if it never existed?
Well...it works!
Here is my current prototype of a pre-deployment script, which I'll go through and cleanup more, but thought I'd share.  I also want to document how I created the temporary assembly_bits in case anyone ever wants or needs to know, even though they really
shouldn't.  But it should make them feel better.  Basically I just created did this to get them:
1 - Created a C# Class Library project in the solution.
2 - Added our .SNK to that project and removed the 'Class1.cs' that it created by default
3 - Signed that class library with the .SNK
4 - Added a project reference to that class library from the main database solution.
5 - Generated a deployment script (but didn't run it) and grabbed the create assembly statement (copy/paste)
6 - Deleted the temporary project
7 - Pasted the code I had copy/pasted into the pre-deployment script
Note that the objects do apparently need to go into MASTER, so at the end of the pre deployment script, I switch back to the automatic [$(DatabaseName)] after first having done USE master.
Hope this helps someone.  Finally got it!
BTW - The other way we almost used was to introduce a SqlCmdVariable of $StrongNameKeyFilePath but that would have been a hassle for people to set whenever they got a new machine, etc.
Thanks,
Ryan
PRINT '**************************************************************************'
PRINT 'Pre\SetupMasterDatabaseKeysAndLoginsIfNecessary.sql'
PRINT '**************************************************************************'
PRINT '************************************************************************************'
PRINT 'If they do not already exist, create the database master key, as well as the asymmetric'
PRINT 'key, from the Strong-Named File (.SNK) which signed the CLR assembly.  Finally, also'
PRINT 'create a login from that asymmetric key and grant it the UNSAFE ASSEMBLY permission.'
PRINT 'This is all necessary b/c the CLR currently has to be referenced for UNSAFE permissions'
PRINT 'in order to access the TimeZoneInfo class.  This code and these objects can be removed'
PRINT 'if the system is ever updated to use all UTC dates and no longer requires the TimeZoneInfo class.'
PRINT '************************************************************************************'
USE master
PRINT N'Creating Temporary Assembly [Wits.Database.AsymmetricKeyInitialization]...'
CREATE ASSEMBLY [Wits.Database.AsymmetricKeyInitialization]
    AUTHORIZATION [dbo]
    FROM 0x4D5BlahBlahBlah;
IF NOT EXISTS (SELECT 1 FROM sys.symmetric_keys WHERE name LIKE '%DatabaseMasterKey%')
    BEGIN
        PRINT 'Creating Master Key...'
        CREATE MASTER KEY
            ENCRYPTION BY PASSWORD = 'I Removed This Part For This Post'
    END
IF NOT EXISTS (SELECT 1 FROM sys.asymmetric_keys WHERE name = 'ClrExtensionAsymmetricKey')
    BEGIN
        PRINT 'Creating Asymmetric Key from strong-named file...'
        CREATE ASYMMETRIC KEY [ClrExtensionAsymmetricKey]
            FROM ASSEMBLY [Wits.Database.AsymmetricKeyInitialization]
    END
IF NOT EXISTS (SELECT 1 FROM sys.server_principals WHERE type_desc = 'ASYMMETRIC_KEY_MAPPED_LOGIN' AND name = 'ClrExtensionLogin')
    BEGIN
        PRINT 'Creating Login from Asymmetric Key...'
        CREATE LOGIN [ClrExtensionLogin] FROM ASYMMETRIC KEY [ClrExtensionAsymmetricKey]
        PRINT 'Granting Permissions to Login created from Asymmetric Key...'
        GRANT UNSAFE ASSEMBLY TO ClrExtensionLogin
    END
PRINT N'Dropping Temporary Assembly [Wits.Database.AsymmetricKeyInitialization]...'
DROP ASSEMBLY [Wits.Database.AsymmetricKeyInitialization]
USE [$(DatabaseName)]