Microsoft Data Migration Assistant - False alarm for signed CLR assemblies?

Andreas Buchfelder 1 Reputation point

Currently, we try to evaluate and solve deprecation issues with our application database.

DMA shows the database was not compatible (breaking change) with SQL Server 2017 and upwards, because of an unsigned custom CLR assembly.

Besides the fact we are using already successfully SQL Server 2017 and 2019 and our assembly IS signed with a certificate, DMA suggests to sign it with a Strong Name Key.


Did someone also have this problem? Microsoft's recommendation on documentation says "Sign with Strong Name Key OR Certificate", so why is this an error?

SQL Server
SQL Server
A family of Microsoft relational database management and analysis systems for e-commerce, line-of-business, and data warehousing solutions.
13,046 questions
SQL Server Migration Assistant
SQL Server Migration Assistant
A Microsoft tool designed to automate database migration to SQL Server from Access, DB2, MySQL, Oracle, and SAP ASE.
502 questions
{count} votes

3 answers

Sort by: Most helpful
  1. Erland Sommarskog 103.2K Reputation points MVP

    If I understand the output from DMA correctly, the assembly is labelled as SAFE, but you have signed it nevertheless?

    It could be that DMA only checks for signing with asymmetric keys - or it does not check at all, since the assembly is safe, and in lower version there were no need check.

    I tend to agree that this is a false alarm.

    0 comments No comments

  2. Seeya Xi-MSFT 16,451 Reputation points

    Hi @Andreas Buchfelder ,

    Please refer to this article about Impact of CLR Strict Security configuration setting.

    Best regards,

    If the response is helpful, please click "Accept Answer" and upvote it, as this could help other community members looking for similar queries.
    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    0 comments No comments

  3. siyao 86 Reputation points Microsoft Employee


    This is breaking change rule and it is not migration blocker issue. It is like what the title and impact says. If the CLR assembly is set as SAFE or EXTERNAL_ACCESS in the current instance and after migrating to 2019, the behavior will be changed and it will be considered as UNSAFE. This is the official doc,,EXTERNAL_ACCESS%20assemblies%20as%20if%20they%20were%20marked%20UNSAFE.