error msb3325 cannot import key file

Question

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

Answer 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 –