When deploying a CLR Assembly that requires EXTERNAL_ACCESS or UNSAFE as the Permission Set you have the option of either Signing the Assembly with a strong key or setting the database to TRUSTWORTHY ON.  Microsoft's recommendation is that you sign the assembly with a strong key as a best practice.

Determining whether to set the Trustworthy Property of a database to ON or to sign your assembly with a certificate might be a confusing thing.  Simply searching online for how to run UNSAFE or EXTERNAL permission Assemblies in SQL Server makes it seem as if setting the Trustworthy Property to ON is the right way to go.  This however is not the Microsoft recommended practice...

One of the most commonly asked questions I get from developers is, should this be done with a CLR function/procedure or in TSQL?  The addition of CLR in SQL Server brought a very powerful extension to the Database Engine.  This article will focus on providing information on how to best make the decision to use CLR or TSQL to solve a problem.

When implementing CLR in SQL Server, often times it easier for developers to use a singe assembly.  This allows them to open a single Visual Studio Solution to add to or change existing CLR.  To a DBA, this can lead to a problem with security in the database server.  Rather than having a single assembly, it is instead better to separate the code out by safety level, placing all Safe Code in a common assembly.  This helps to minimize the volume of code that has to be reviewed by the DBA to know how safe the Assembly is.

Learn how to enable CLR for the SQL Instance and set your database to the correct compatibility level for running CLR.