Why do you say that the DLL is not signed? Did you inspect the DLL with a tool that can check for strong names (which is different than using a certificate to sign the assembly / DLL)? SN.EXE is what is used to strongly name the assembly. And it can extract a strong-name as well to confirm that it indeed has a strong name.
I suspect that the DLL / assembly is strongly named (i.e. signed) but that it cannot be deployed because Visual Studio (and more specifically, SSDT, which handles the building of the SQL script and deployment) has never understood the concept of SQLCLR security (probably because SSDT Database Projects are just that, database-level, not instance-level). So, unfortunately, we are left to deal with proper deployments ourselves ("proper" meaning not enabling TRUSTWORTHY for the DB).
I have instructions for two different approaches to this problem, both working with SQL Server 2017 and newer (older versions do not have the absurd and counter-productive "CLR strict security" server config option), and both being automatable.
For more details and explanation, please see my answer to the following question (also here on S.O.):
CLR Strict Security on SQL Server 2017