Any reason to ship .snk file with the project sources?

Every now and then I see a 开发者_如何学Gosample project on the network which contains a .snk file used for signing the compilation results with a strong name.

AFAIK this is plain wrong - once a .snk file is disclosed anyone can produce an assembly that can be used to replace an assembly shipped by the original code supplier but now containing malicious code. I suppose that people shipping .snk files don't treat that risk seriously and just ship the file because otherwise the project wouldn't compile off-the-shelf.

Is there any reason for shipping the .snk file except that "convenience"?

A very valid question. I for my part do not ship the SNK file but do provide instructions how to produce one yourself and make the required changes (to enable InternalsVisibleTo for instance).

I think that the current practice has been pushed my Microsoft with the changes in the SNK handling starting with VS2005. Using a key container requires a manual edit of the CSPROJ file with an undocumented MSBUILD item KeyContainerName... the default of VS is to copy the SNK into the project directory, which is convenient but wrong IMHO.

The only reason I can think of, is to allow a drop-in replacement for your dll...

Of course, normally I'd say "don't sign your dll if you want drop-in replacements." but if it's installed in the GAC signing is a pre-requisite. (or was, last time I knew).

So allowing replacements for your dll that is installed in the GAC. Is the only rational reason I can think of...

At least, I can't see a reason to ship both, the private and the public keypair together. If you need to ship source code you could alternatively use a .pfx which has improved security through the password you'll need to sign the assembly.

Anyhow, it seems to be common practice (bad practice) in a lot of open source projects to add the .snk file to the source control. So a very good question!