每隔一段时间我都会在网络上看到一个示例项目，其中包含一个用于用强名称签名编译结果的.snk文件。是否有任何理由将.snk文件与项目源一起发布？
AFAIK this is plain wrong - 一旦.snk文件被披露，任何人都可以生产一个组件，可以用来替换原始代码供应商提供的组件，但现在包含恶意代码。我想运输.snk文件的人不会认真对待这种风险，只是运送文件，因为否则该项目将无法现成编译。
运送.snk文件除了“方便”之外是否有任何理由？
一个非常有效的问题。我为mypart不要运送SNK文件，但要做provide instructions如何自己生成一个并进行必要的更改（例如启用InternalsVisibleTo）。
我认为，目前的做法已经推动我的微软与VS2005开始SNK处理的变化。使用密钥容器需要使用无证MSBUILD项目KeyContainerName手动编辑CSPROJ文件... VS的默认值是将SNK复制到项目目录中，这很方便，但却是错误的。
至少，我看不出有理由将两者，私人和公共密钥对一起运送。如果您需要发布源代码，您可以使用通过密码提高安全性的.pfx，以便签署程序集。
无论如何，在很多开源项目中，将.snk文件添加到源代码管理中似乎是很常见的做法（不好的做法）。所以一个非常好的问题！
我能想到的唯一理由，就是让一个下拉更换为DLL ...
当然，通常我会说：“如果你要滴不签你的DLL替代品“。但如果它安装在GAC签名中是一个先决条件。 （或者，上次我知道）。
因此允许替换您的dll安装在GAC。是我能想到的唯一理性原因...
强名称是必须的恕我直言：你不能签署一个引用未签名程序集的程序集，因此这会创建一个未签名程序集链。在未签名的程序集上，版本未被检查AFAIK，这使得它们非常不安全，因为你再次打开DLL地狱的大门。 – Lucero 2011-01-31 12:17:51