1

I recently cloned a build machine, renamed the machine on the domain, and moved the machine from a SATA drive to a SSD drive.

I am trying to setup a new build for a new branch within SVN. The application is a combination of Visual Studio 2010 C# and VB.NET code and VB6 code

When the first project tries to compile from the command line it fails to compile with the error: "error MSB3325: Cannot import the following key file: "MyFile1.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_##########"

Now I can open the Visual Studio 2012 IDE and build the project successfully, both Release and Debug mode. In any order.

Things I have tried to resolve this:

  1. I have opened the proj file and selected properties, signing, and tried selecting the "MyFile1.pfx" file again.
  2. I have tried signing the MyFile1.pfx file again.
  3. I have left the Visual Studio 2012 project open, and opened a command window. I have tried 'sn -i xxxxx.pfx VS_xxxxxxx", enter password when prompted
  4. I have tried manually editing the .*proj files and removing references to MyFile1.pfx file and rebuilding the projects and then adding the "MyFile1.pfx" file again.

In each of these cases, the command line build fails and the Visual Studio build succeeds.

My command line build is us using the solution files for the build and calls devenv.com to build the solution.

I am confused as to why the IDE build works and the command line does not, my guess it has something to do with building from the .com verses the exe.

Is there anything else I can do other than building up a new build machine from scratch for this branch build?

Thank you.

Dan

Daniel Lee
  • 674
  • 1
  • 9
  • 25
  • I do want to clarify, that if I remove the digital signing flag, that the build does complete successfully, however, digital signing is desirable. :D – Daniel Lee Feb 26 '13 at 18:16
  • Ok, **I found a solution** (but I cannot post it yet). It is strange but true. It deals with the Cruise Control Service of all things. *If anyone else encounters a similar problem* check the services properties for Cruise Control. Click on Log On tab Check the 'This Account' settings, if set. Make sure the setting for the first run at least are the current user. My settings were set for the local Administrator account and I do not log in as the local administrator when setting up a machine. Hopefully this helps anyone else trying to chase down a rogue file signing problem. Dan – Daniel Lee Feb 26 '13 at 19:38
  • Possible duplicate of [Cannot import the keyfile 'blah.pfx' - error 'The keyfile may be password protected'](http://stackoverflow.com/questions/2815366/cannot-import-the-keyfile-blah-pfx-error-the-keyfile-may-be-password-protec) — though I see you tried the accepted answer. But there is a lot of other stuff there, so it would make sense to give your answer as an alternative answer there. – PJTraill Oct 28 '16 at 13:52
  • You could include a reference to http://stackoverflow.com/questions/2815366/cannot-import-the-keyfile-blah-pfx-error-the-keyfile-may-be-password-protec – PJTraill Oct 28 '16 at 13:53

1 Answers1

1

Ok, I found a solution.

It is strange but true. It deals with the Cruise Control Service of all things. If anyone else encounters a similar problem check the services properties for Cruise Control.

  1. Open Services.msc
  2. Click on Log On tab
  3. Check the 'This Account' settings, if set. Make sure the setting for the first run at least are the current user.

My settings were set for the local Administrator account and I do not log in as the local administrator when setting up a machine. Hopefully this helps anyone else trying to chase down a rogue file signing problem.

Dan –

Daniel Lee
  • 674
  • 1
  • 9
  • 25
  • 1
    This same situation holds true no matter what system you are using for managing your builds. I recently setup a teamcity build system and had the same problem. The issue was that the build was operating under NT AUTHORITY/System with my default setup. However, I have to run under the current user at least once to get the keys to register. – Daniel Lee Sep 16 '13 at 20:31