I’ve recently rebuilt my development machine and downloaded my solution from the source repository, and Visual Studio gave me this error the first time I tried to compile.
Cannot import the following key file: magellanicKey.pfx. The key file may be password protected. To correct this, try to import the certificate again or manually install the certificate to the Strong Name CSP with the following key container name: VS_KEY_883A9453A40E283F
The error is pretty informative – CSP stands for ‘Cryptographic Service Provider’, and the message is telling me that it can’t import a private-key/public-key pair file called
magellanicKey.pfx. That’s because my new machine doesn’t have any records of what password is required for this key file. Since VS expects to be able to import the file but can’t, we get an error.
I should have predicted this error! Since I don’t like seeing error CA2210 coming up after running Code Analysis[*], I make sure that all my assemblies are strongly named, which means that I have to sign my assemblies with a private-key/public-key pair file. This file is password protected and I’m the only one who knows the password. (If I open the project up to more developers, I’ll use delay signing so I don’t have to reveal that password.)
This is an easy problem to solve using sn.exe, the Microsoft Strong Name Utility.
I just right click on the pfx file from VS Solution Explorer and select “Open Command Prompt”. A prompt opens right at the folder containing the key file, and I enter the command:
sn -i magellanicKey.pfx VS_KEY_883A9453A40E283F
(Note that the long string beginning with ‘VS_KEY_88…’ is only relevant for my machine – you will have to use the specific value from your error message, so don’t just copy and paste the command above because it won’t work).
After I run this command, I’m challenged for the key file’s password- I enter the password, hit enter, and the key pair is successfully installed on my new machine. I can now compile the project through Visual Studio without error.
[*] Side note: Actually, avoiding the CA2210 warning isn’t the main reason that I strongly name my assemblies. The main reason is that when people use my assemblies, I want them to be sure that the assembly has come from me (and hasn’t been tampered with). Another good reason not to use weakly named assemblies is that they can only be used in weakly named projects – another way of saying this is that strongly named projects cannot use weakly named assemblies, so by leaving your assembly as weakly named, you might unwittingly be causing a problem for your customers. Finally, strongly named assemblies can live in the GAC if necessary – weakly named assemblies cannot. There’s a great article on O’Reilly if you want to read more about strong naming, and another one here on MSDN.