是否有任何理由将.snk文件与项目源一起提供? [英] Any reason to ship .snk file with the project sources?

问题描述

我时不时地在网络上看到一个示例项目，其中包含一个.snk文件，用于使用强名称对编译结果进行签名.

AFAIK 这是完全错误-一旦披露了.snk文件，任何人都可以生产一个程序集，该程序集可用于替换原始代码提供者提供的但现在包含恶意代码的程序集.我认为运送.snk文件的人们不会认真对待这种风险，而只是运送文件，因为否则该项目将无法立即编译.

除了方便"之外，是否有任何其他原因来运送.snk文件?

解决方案

一个非常有效的问题.我是我 提供说明如何自己制作并进行所需的更改(例如，启用 InternalsVisibleTo ).

我认为，从VS2005开始，当前的做法已经推动了Microsoft对SNK处理的更改.使用密钥容器需要使用未记录的MSBUILD项目 KeyContainerName 手动编辑CSPROJ文件... VS的默认值是将SNK复制到项目目录中，这很方便，但是恕我直言./p>

Every now and then I see a sample 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.

这篇关于是否有任何理由将.snk文件与项目源一起提供?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！