Strong naming and error when compiling in VS2010 and Team City

In Visual Studio 2008, when we added a password-protected strong name to an assembly (a .pfx file), and we wanted to build it in another machine, it would prompt us to enter the password when we tried to build it.

In the transition to Visual Studio 2010, everything kept working perfectly. But when we added a new assembly and its .pfx, when we tried to build in another machine, it didn't ask for the password, and failed with this message (key file number is anonymized):

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

First of all, to fix this in our Visual Studio (and our colleagues'), we must go to project's Properties, then to the Signing Tab. There, in the list box where we select the .pfx, click Browse and hit the existing .pfx file. When we do that, we will be prompted for the password. Yes, it's a Visual Studio 2010 bug and hopefully it will be fixed soon.

And what if we use a Continuous Integration server like Team City? Well, we have to do what the error message says: import the certificate manually. This can be done using the sn.exe program which comes with the Windows SDK, and is usually found at %ProgramFiles%\Microsoft SDKs\Windows\v7.1\Bin (your SDK version might differ). The syntax is the following:

sn -i pfxFile.pfx VS_KEY_xxxxxxxxxxxxxxxx

The command arguments' values are those reported by the error message.

However, there's a catch. By default, Team City's build agent runs under Windows' SYSTEM account, which, in case you didn't know, has a few more privileges than the Administrator account. Unless we configured Team City to not run under SYSTEM, we'll have to open a cmd under the SYSTEM account to run the sn command line from above.

Now the question is, how do we open a cmd under the SYSTEM account? Simple, download PSTools, and unzip in C:\Windows or some other location referenced by the PATH system environment variable, so that we can run it from anywhere. Once that's done, open a cmd as Administrator and type:

psexec -i -s cmd.exe

This will open another cmd under the SYSTEM account. Here, run the sn.exe with the proper values and the error should go away.

Comments

Popular posts from this blog

VB.NET: Raise base class events from a derived class

Apache Kafka - I - High level architecture and concepts

Upgrading Lodash from 3.x to 4.x