Using a signed dependency in two Visual Studio instances, one elevated/administrator, one normal

Question

I am running Visual Studio 2012 and writing a backend web service and desktop software in separate solutions. Because the desktop software needs to run elevated ("as administrator"), I need to run the desktop solution in an elevated Visual Studio instance. Both solutions include a signed library project.

When I open the web service solution in a Visual Studio instance without elevating it, I get a build error like

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

When I attempt to fix this by doing that, it fails with an error message saying that the key already exists.

When I attempt to exclude and then re-include the PFX file does not put things right, but makes the "strong name key file" dropdown in Project Properties → Signing blank. Following this, the web service solution builds, but it seems that the library does not get signed since in the (elevated) desktop solution, builds fail with "Assembly generation failed -- Referenced assembly 'redacted' does not have a strong name".

If I try to choose the PFX file again from the dropdown within the web service solution (and reenter the password), I get:

Error importing key
An attempt was made to reference a token that does not exist

Setting the PFX file from the (elevated) desktop solution works, but returns me to square one.

It seems that depending on elevation, Visual Studio looks in different key stores for access to whatever unlocks the PFX. Do I have to run both instances of Visual Studio elevated to work around the problem or can I somehow tell it to look in the same place?

Guttle

does it work if you include the AssemblyKeyFile hardcoded? – Holmann

Is there a reason you don't want to run both "As Administrator"? -- it seems to make all my code signing headaches go away, and the only downside I've found is that you need to make a registry entry for context sharing (i.e. mapped drives and such) to work right. [FYI, details on the registry entry can be found here: winability.com/… ] – Jessicajessie

I am currently running both as Administrator and that fixes it. My concerns are that I want to run with as little variability as possible on all my projects and, since some run fine without needing elevated privileges, as few as possible without running as Admin. Microsoft has more or less broken the ability to set Visual Studio to always run elevated (I've gotten close but it breaks double clicking solutions) and yet you can't always get by running Visual Studio without elevation. – Guttle

Answer 1

@ccpanda's comment solved this. Including an AssemblyKeyFile archive makes this work. E.g.:

[assembly: AssemblyKeyFile("HerpDerpWarblerManagementStudioProTM.snk")]

The long and short of this is that the two Visual Studios will assume different things depending on their mode. The solution isn't to make them assume the same thing, it's to tell them what to do.

(I've chosen to use an .snk file since that's the way you have to do it if you don't want to re-enter a password every time every other developer tries to build. This question has a lot more information. Basically, you have to either use an .snk file or make your build process compile and then sign the file with an invocation of sn.exe that will somehow know to use a .pfx file for everyone.)

(@ccpanda: If you write your comment as an answer (and maybe you did and Stack Overflow helpfully decided it was trivial), I will mark it as an answer.)

Guttle