views:

2992

answers:

6

We just upgraded our Visual Studio 2008 projects to VS2010. All of our assemblies were strong signed using a Verisign code signing certificate. Since the upgrade we continuously get the following error:

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

This happens on some developer machines and not others. Some methods used to fix this that worked some of the time include:

  • re-installing the key file from Windows Explorer (right click on the PFX file and click Install)
  • installing VS2010 on a fresh machine for the first time prompts you for the password the first time you open the project, and then it works. On machines upgraded from VS2008, you don't get this option.

I've tried using the SN.EXE utility to register the key with the Strong Name CSP as the error message suggests, but whenever I run the tool with any options using the version that came with VS2010, SN.EXE just lists its command line arguments instead of doing anything. This happens regardless of what arguments I supply.

Does anyone know WHY this is happening, and have clear steps to fix it? I'm about to give up on Click Once installs and Microsoft Code Signing. Thanks for any help!

A: 

i tried the workaround over here https://connect.microsoft.com/VisualStudio/feedback/details/524792/importing-key-file-was-canceled?wa=wsignin1.0

without success - did you found already a solution?

Hey - no success either. I've started a trouble ticket with Microsoft and they've said it's a problem with VSS and VS2010. You can easily fix the build for 1 user using this technique: (a) open the solution, (b) check out the PFX file, (c) open the project properties page, and go to the signing tab, (d) click on the change password option for the signing certificate and re-enter the old password and use the same password for the new password and confirm new password (e) check the file in.From now on the build will be good - for you. For everyone else it will still be broken.
JasonD
+9  A: 

I was running into this problem as well. I was able to resolve the issue by running sn -i

Based on your post that would look like

sn -i companyname.pfx VS_KEY_3E185446540E7F7A

This must be run from the location of your PFX file, if you have the solution loaded in VS 2010 you can simply right click on the pfx file from the solution explorer and choose Open Command Prompt which will launch the .net 2010 cmd prompt tool in the correct directory.

Before running this sn command I did re-install the pfx by right clicking on it and choosing install however that did not work. Just something to note as it might be the combination of both that provided the solution.

Hope this helps solve your problem.

Brandon Manchester
Thanks Brandon - yes this, like the manual re-install of the key file "sort of" solves the problem. The issue is that as soon as you check in the key file, any other users that get latest on this checked in key file are now going to experience this bug. If any of those users check in their "fix" and I get latest, then my machine is now broken again... and so on.Microsoft have started a trouble ticket on this and assigned it to the VS2010 team and the VSS team.
JasonD
Interesting.I did not run into that problem when adding the pfx to the new CSP. To my knowledge SN -i does not change the pfx file so you shouldn't have to check anything in afterwards.However if you were to change the pfx file in anyway such as resetting the password, that would cause an issue since it would change the pfx file.Does your solution build with that pfx file from any other machine? If so then the pfx file is correct just not set to the correct CSP on your machine that is having build issues.
Brandon Manchester
At first I tried only the sn -i part but it complained that the password was incorrect (though it was correct). I removed the certificate, reinstalled it and then sn -i... worked.Basically confirming that for me, both steps were required. Reinstall cert then execute the sn command.
Dodgyrabbit
I've found in both VSS and TFS that if you run the sn -i command it doesn't work unless you have the PFX file checked out, and when you check it in it doesn't work for other developers on the network. I'll have to try the re-install cert then run the sn -i command. We need it to work on all developer machines in the office.
JasonD
+1  A: 

As the original author of the work around on the connect bug report, there are TWO variants of this message (I've discovered later)

For one variant you use sn.exe (usually if you are doing strong naming) to import the key to the strong naming store.

The other variant for which you use certmgr to import is when you're codesigning for things like click-once deployment (note you can use the same cert for both purposes).

Hope this helps.

PeterI
Yeah, we tried that one with Microsoft support as well, and that's the way to do the code signing import. The problem really seems to be that the certificate password gets lost during the checkin process source safe. But this doesn't look to be the real problem. It looks if you enter the certificate details on Widnows 7 machine #1, and then move that exact same file to a different machine and register it, the registration will work, but the build will fail. Microsoft are still looking into it for us. For now we had to disable code signing and sign manually during release.
JasonD
A: 

As a workaround, i tried running the vs2010 as an administrator and it worked for me.

Hope this helps.

+5  A: 

I've discovered a fix that helps you be able to build successfully in a multi developer environment:

Instead of changing the password (which causes the .pfx to be changed), reselect the .pfx file from the combobox. This then invokes the password dialog. After entering the password, the project will build OK. Every dev can do this on his local machine without actually modifying the .pfx file.

I'm still having problems getting assemblies to be signed on our build server machine. I'm getting the same error there, however using the sn.exe -i method does not fix the problem for the buildserver.

MagicBox
+2  A: 

VSCommands 2010 (plugin for Visual Studio) can fix this for you automatically - just right-click on error and click Apply Fix from menu. You can get it from visual studio gallery http://visualstudiogallery.msdn.microsoft.com/en-us/d491911d-97f3-4cf6-87b0-6a2882120acf

jarek