Any reason to send a .snk file with project sources?

Question

From time to time I see an example of a project on the network that contains a .snk file used to sign compilation results with a strong name.

AFAIK This is wrong. - as soon as the .snk file is opened, anyone can create an assembly that can be used to replace the assembly sent by the source code provider, but now containing malicious code. I believe that people sending .snk files do not take this risk seriously and simply send the file because otherwise the project will not compile the finished ones.

Is there any reason for delivering a .snk file besides this “convenience”?

Answer 1

Very correct question. I for my part do not send the SNK file, but does provide instructions on how to make them yourself and make the necessary changes (for example, enable InternalsVisibleTo ).

I think that current practice has prompted my Microsoft to change SNK processing, starting with VS2005. Using the key container requires manual editing of the CSPROJ file with the undocumented element MSBUILD KeyContainerName ... by default, VS is copying SNK to the project directory, which is convenient, but incorrect IMHO.

Answer 2

The only reason I can think of is to allow the replacement of your DLL replacement ...

Of course, I would usually say that "do not sign your dll if you want a replacement for a replacement." but if it is installed in the GAC signature, this is a prerequisite. (or was, the last time I knew).

So, let's replace your DLL installed in the GAC. Is the only reasonable reason I can think of ...

Answer 3

At least I see no reason to send both private and public key pairs. If you need to send the source code, you can also use .pfx, which has improved security with a password that you will need to sign.

In any case, it is common practice (bad practice) in many open source projects to add a .snk file to the source control. So a very good question!