The error is a result of the new `clr strict security` server-level configuration option in SQL Server 2017. This new security setting disallows _any_ Assembly, even those marked as `SAFE`, from being either created or loaded into memory for execution, unless:

* the Database property of `TRUSTWORTHY` is `ON` (don't do this as it is an unnecessary security risk)
* the Server-level configuration option of `clr strict security` is disabled / `0` (don't do this as it is an unnecessary security risk)
* the Assembly is signed _and_ you have a corresponding signature-based Login that has been granted the `UNSAFE ASSEMBLY` permission (_please_ do this)
* the SHA-512 hash of the Assembly is registered as a "Trusted Assembly" (absolutely _never_ do this as there are numerous problems with it, not to mention that it was never needed in the first place)

All you need to do in order to fix this situation are the following steps (which are not difficult _and_ provide the highest level of security):

1. Create a Certificate in the Database where the Assembly resides
1. Back up the Certificate (both Public and Private Keys) to files
1. Sign the Assembly (or Assemblies) with the Certificate
1. Remove the Private Key (it can be restored later from the backup file)
1. For each additional Database that has unsigned, `SAFE` Assemblies:
  1. Either skip this sub-step (i.e. skip to Step 6), complete the steps, and repeat the whole process (this will result in one Certificate per each Database needing one), _OR_
  1. Do the following (this will result in one Certificate total, which will be used for all Databases):
      1. Create the same Certificate from the backup files (including the Private Key!)
      1. Sign the Assembly (or Assemblies) with the Certificate
      1. Remove the Private Key (it can be restored later from the backup file)
1. Copy Certificate to `[master]` (Public Key only!)
1. Create Login from Certificate


A simple example of this would be:

    USE [{database_containing_unsigned_safe_assembly}];
    
    CREATE CERTIFICATE [{certificate_name}]
      ENCRYPTION BY PASSWORD = '{some password}'
      WITH SUBJECT = '{simple description}',
      EXPIRY_DATE = '2099-12-31';
    
    ADD SIGNATURE
      TO Assembly::[{assembly_name}]
      BY CERTIFICATE [{certificate_name}]
      WITH PASSWORD = '{some password}';
    
    DECLARE @PublicKey VARBINARY(MAX),
            @SQL NVARCHAR(MAX);
    
    SET @PublicKey = CERTENCODED(CERT_ID(N'{certificate_name}'));
    
    SET @SQL = N'
    CREATE CERTIFICATE [{certificate_name}]
      FROM BINARY = ' + CONVERT(NVARCHAR(MAX), @PublicKey, 1) + N';';
    PRINT @SQL; -- DEBUG
    
    EXEC [master].[sys].[sp_executesql] @SQL;
    
    EXEC [master].[sys].[sp_executesql] N'
    CREATE LOGIN [{login_name}]
      FROM CERTIFICATE [{certificate_name}];

    GRANT UNSAFE ASSEMBLY TO [{login_name}]; -- REQUIRED!!!!
    ';

A fully working example of this (minus the backup and Private Key removal) can be found on PasteBin:  
[Avoiding "Trusted Assemblies" - Demo][1]

A detailed explanation of why you _should_ use Certificates, and why you should _not_ use "Trusted Assemblies", to fix this problem is provided in my blog post:  
[SQLCLR vs. SQL Server 2017, Part 4: “Trusted Assemblies” – The Disappointment][2]

Also, please consider supporting my request to have Microsoft remove the new "Trusted Assemblies" feature given the numerous problems surrounding it (including security concerns), and the overall lack of benefits for having it:

[Trusted Assemblies are more problematic yet less functional than Certificates - Please Remove][3]


  [1]: https://pastebin.com/mwi5BidL
  [2]: https://sqlquantumleap.com/2017/08/28/sqlclr-vs-sql-server-2017-part-4-trusted-assemblies-the-disappointment/
  [3]: https://feedback.azure.com/forums/908035-sql-server/suggestions/32898688-trusted-assemblies-are-more-problematic-yet-less-f