views:

176

answers:

1

In the visual studio project settings you can choose a strong name key file for signing the assembly. When creating a new one you can choose to protect it with a password. When should you do this? And when should you not?

I am thinking that it could for example be not so smart to protect it with a password if the project is an open source project hosted on Codeplex or similar. Or should it still be protected? Will people be unable to download the source and compile it if the key file is protected? Or, how does this work exactly?

+1  A: 

In general, you should protect it with a password if you don't trust the people with access to it. Anyone with access to the key file can create an assembly with your strong name (unlike authenticode, they're not impersonating you, but they can get they're assemblies to load instead of yours)

As for the open source scenario you described, people can always compile the code - they simply create a new key file, but the assemblies they create will not be loaded by assemblies that try to load your assemblies.

On Freund
Ooh. So, if I have two assemblies which are signed with strong name keys. If I then add a reference from one to the other, it will only work with the one that was signed with the right key?
Svish
If you reference a strong name assembly, it cannot be replaced at run-time with an assembly signed with a different key (not entirely correct, but let's leave the more advanced stuff out for now)
On Freund
And by *at run-time* you mean when the application is run, not while it is running, right? (Just to be sure I don't misunderstand :p)
Svish
I'm not sure I understand your distinction between run and running... What I mean is that when the assembly reference is resolved, the chosen assembly must have the same strong name.
On Freund
My *while running* I meant swapping out the assembly after it had been resolved, while the application was running. But I think I got what you meant now :)
Svish