Fixing Strong Name password Errors

Strong name key file password "incorrect"; "specified network password is not correct"

This has happened to me twice in the last six months, and I keep forgetting the incredibly simple fix, so I’m posting it here, both for my own use, and in the hope that I can help someone else.

Here’s the scenario: you are merrily programming away in Visual Studio 2005 or 2008, with a project open which you have signed with a Strong Name, which in turn you have protected with a password. Then, boom! Either Visual Studio , or Windows itself, crashes; or, maybe one of those @#$%& Windows Updates re-starts your PC when your back is turned.
Fingers crossed, you boot up, open Visual Studio, and there it is– you are greeted with a message offering to recover a file that was open at the moment of "disaster". Of course, you choose Yes; and then either Visual Studio, or you, open the Project that was open. Everything looks fine, until you try to build/debug; then you get a message asking for the password to your Strong Name key file, so the key can be "imported". This seems curious, since the key should already be there; you even see the file if you look at Project Explorer on the right side of the Visual Studio window. But, whatever; you enter your password. And that’s when this issue rears up and smacks you in the face.

Your password is rejected; "network password?? this is a key file, not a network resource!"

"Hmm…that’s strange…I’m pretty sure that’s the correct password…oh well, let me try again." So you try again…and get either an "incorrect password" message, or a really strange one: "specified network password is not correct". "But I’m not trying to access anything on the network!! What gives??"

At this point, I thought I recalled fixing this by un-checking the "Sign the assembly" checkbox in the Project properties, building the project, then signing it again; but that didn’t work this time.

Update from the source code repository?

That was my next thought; it didn’t work. I didn’t go as far as checking out a new working copy into a new directory, so I don’t know if that would have worked; but, as it turns out, that would have been overkill. There’s a much simpler solution. Read on…

Close and re-open the Project?

That’s what I tried next; still no luck. Finally, I remembered what had worked the last time:

The solution: close, and re-open, Visual Studio, and then re-open the Project

Sure enough, that fixed the problem. So simple…

The moral of the story

So often, we get stuck in a rut in our thinking as developers. Whether it’s our approach to a programming problem, the proper fix for a bug, or an issue with one of our tools, we keep metaphorically throwing things against the wall, hoping something will stick. In my case, I sometimes spend way too long Googling exact error messages, hoping someone has "been there" before me; this approach has succeed so often for me that I sometimes fail to stop and look for another way when I should. I am also way too hesitant to re-start Visual Studio, or even re-boot Windows, when something "gets stuck". In this case, it would have saved me some time.
Advertisements
  1. #1 by Katelyn on November 20, 2014 - 9:56 am

    Closing and re-opening Visual Studio worked for me too. Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: