I have a database project in VS, and am trying to generate an asymmetric key in SQL Server from the dll. In SSMS, I am trying to run the following:
CREATE ASYMMETRIC KEY MyNewKey
FROM EXECUTABLE FILE = N'C:\{path to dll}\MyDBProj.dll'
The error I get is "The certificate, asymmetric key, or private key file is not valid or does not exist; or you do not have permissions for it."
The dll in question was built with SQLCLR permission level = SAFE
My assumption is that it is related to file permissions, but I don't know what security permissions I need to allow on the file to make this happen. I was informed that I should give the NETWORK SERVICE account read access, which I did.
This is on a local db with mixed mode authentication. I've tried as both Windows user and under the sa account.
Given that you are using SQL Server Express LocalDB (which runs as your Login and hence has no permissions issues), the only thing that should cause such an error is if you did not actually sign the Assembly. That can be done in Visual Studio via the "Signing..." button in the SQLCLR tab of Project properties.
Signing an Assembly (whether by giving it a strong name or adding a Certificate) places the public key of whatever was used to sign it inside the Assembly. The CREATE ASYMMETRIC KEY statement will extract a public key from an Assembly that was placed there by strong naming it. This is not the same as getting the public key of a Certificate that was used to sign the Assembly as they are stored separately.
Of course, if by "a local db" you meant that it is merely running on your dev workstation and is not specifically SQL Server Express LocalDB, then I guess it would be SQL Server Express? If you logged into SQL Server as yourself (you said you tried as a Windows user) and you are a sysadmin, then there still shouldn't be any file system permissions issues, nor any issue with creating an Asymmetric Key.
General
For more information on working with SQLCLR in general, please see the series that I am writing on this topic on SQL Server Central: Stairway to SQLCLR.
Regarding SQL Server 2017
SQL Server 2017 introduced a new security feature ("CLR strict security", an advanced option) that is enabled by default and requires that ALL Assemblies, even those marked as SAFE, be signed with either an Asymmetric Key (i.e. strong name) or Certificate and have a Login (based on whatever was used to sign the Assembly) that has the UNSAFE ASSEMBLY permission. For details on how to make this work, with or without Visual Studio / SSDT, please see the following two posts of mine:
Please avoid the new Trusted Assemblies "feature" as it has many more flaws than benefits, not to mention it being entirely unnecessary in the first place given that existing functionality already handled the situation "Trusted Assemblies" was meant to address. For full details on that and a demo of the proper way to handle existing, unsigned Assemblies, please see: SQLCLR vs. SQL Server 2017, Part 4: “Trusted Assemblies” – The Disappointment.