Strong Name sn.exe: Failed to install key pair -- Object already exists
Asked Answered
E

2

36

I have 2 different versions of the same project on my machine. One from the code trunk, and the other from a code branch. These projects use a .pfx key to enable strong naming. When I first tried to compile the trunk version of the project I get the following error:

Cannot import the following key file: sgKey.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_45891C38BC1BB345

To resolve this I use sn.exe with the following command:

sn -i sg Key.pfx VS_KEY_45891C38BC1BB345

This resolves the issue with the trunk project, which then happily builds.

However, when I try to build the branch version of the project, I receive the same initial error (with the same key container name), and when I try install the certificate using the sn.exe it (not surprisingly) gives the following error:

Failed to install key pair -- Object already exists

This makes sense in that I used the same infile and container on the sn command, but what I am trying to understand is:

  1. If this object already exists, why is the project failing to build, as it would appear the certificate is already installed.
  2. How I resolve this (e.g. can I uninstall and then reinstall? and if so, how?)
Ensample answered 20/5, 2014 at 7:56 Comment(0)
E
68

I have managed to resolve my issue, without fully understanding the cause. I found a post about a similar issue here, but did not fit my circumstance precisely, as I had only ever logged on to my machine as a single user.

The post showed how to delete the container, but I couldn't do this either as it said the container didn't exist. What it did though was prompt me to run the command prompt as an Administrator, which I had not done previously. This allowed me to uninstall and re-install the certificate, and both versions of the project now build successfully.

My assumption is that somehow the certificate had initially been installed (by me) under a different user than the one I tried to install with the second time, though I don't know why this would be, as I have only ever logged on to the machine as a single user. It remains something of a mystery to me.


Summary:

  1. Start the developer command prompt as administrator, otherwise you'll get a misleading error saying the container doesn't exist.
  2. Run sn -d VS_KEY_XXXXXXXXXXX to remove the old key.
  3. You should now be able to reinstall the certificate.
Ensample answered 20/5, 2014 at 8:17 Comment(6)
Thank you so much for following up on this. This is exactly the situation I was in, and your fix worked for me. I had originally logged into Windows 8.1 using my Microsoft account, installed the certificate, then realized I meant to log into Windows as my domain user. I deleted the old user account from the machine, but apparently the previous certificate install (still) had ill effect. Don't forget to mark your answer as correct.Grew
I am glad I could be of assistance John, and thanks for the edit summarising the steps.Ensample
Thanks for the answer, saved my sanity. One note for those that follow though, after resinstalling the key I had to restart Visual Studio to get it to notice the change.Lanalanae
Thanks for the answer @Chris. It solved my existance ;)Eosinophil
Where to find the VS_KEY_XXXXXXXXXXX??Rental
If you are receiving the “Cannot import the following key file: sgKey.pfx”, it will be at the end of that message. See my original postEnsample
W
6

We had the same problem after doing a "refresh" on Windows 10. Here's what worked for us:

  1. Start a command prompt as administrator.
  2. Run "sn -m n" to make certificates user-based rather than machine-based.
  3. Install the certificate as normal (either "sn -i VS_KEY_XX" or using the "properties" dialog in VS).

It was like the refresh stored the old containers in some hidden area, where they couldn't be deleted (but also interfered with the addition of the same container). Changing to user-based allows a clean slate from the current user's perspective. Note that if you have multiple users on the same machine, they would probably each need to register the certificates.

Wring answered 28/11, 2017 at 19:39 Comment(1)
Thanks you saved me!Playground

© 2022 - 2024 — McMap. All rights reserved.