.NET:可执行文件应该进行强名称签名吗？私有(private) DLL 怎么样？

Question

我的应用程序由三个程序集组成:一个引用几个 DLL 的 EXE。这些 DLL 是我的应用程序私有(private)的 - 它们仅由该可执行文件使用。

应该给这些程序集一个强名称吗？

FxCop 建议他们应该 - 对于目前生产的所有组件:

CA2210: Sign <assembly> with a strong name key.

但是，this advice说:

In general, you should avoid strong-naming application EXE assemblies.

和

you may want to avoid strong-naming components that are private to your application.

我应该给这些程序集一个强名称吗？在这种情况下这样做(或不这样做)有什么好处？

编辑:

看了几个具有相似结构的应用程序，在这个问题上似乎没有达成共识。 Paint.NET 的二进制文件和 Crack.NET不是强名称，而.NET Reflector的那些和 Snoop是。

有趣的是，对于 Expression 套件，Microsoft 采用了后一种方法:例如，在 Expression Blend 中，他们选择对 Blend.exe 和随附的 DLL(例如 Microsoft.Expression.Blend.dll)进行强名称签名.

似乎我不太可能收到第一个问题的简单答案:“我应该给这些程序集起一个强名称吗？”。然而，我的第二个问题仍然存在:

在这种情况下，强名称签名二进制文件有什么好处吗？或者，不这样做有什么好处吗？

编辑2:

如果没有压倒性的理由采取任何一种方式，我倾向于给我的程序集一个响亮的名字。因此，我很想知道是否有人可以对此进行扩展(从第一个链接):

“强命名会使管理依赖项变得更加困难，并为私有(private)组件增加不必要的开销。”

Answer 1

据我所知，在这种情况下强名称签名的好处如下:

• 防止攻击者用使用另一 key 签名(或根本未签名)的 DLL 替换 DLL，而无需替换 EXE(因为 EXE 包含包含公钥的引用)。
• 防止攻击者在保留现有 key 的同时修改程序集(因为这将导致签名验证失败)。但请注意，从 .NET 3.5 SP1 开始，这种情况下的签名验证为 disabled by default .
• 可以防止应用程序使用不匹配版本的程序集运行 - 如果由于部署错误而错误地替换了 DLL，应用程序将无法加载它，而不是尝试使用(可能不兼容的)错误版本。<
• 避免 FxCop 警告。

以及签名的缺点(我相信这些是链接文章所指的内容):

• 用兼容的较新版本替换 DLL(例如，为了修复错误)需要替换 EXE。
• 在 .NET 版本 < 3.5 SP1 中，由于签名验证，强名称程序集的加载时间较长。
• 强名称 DLL 的加载时间也较长，因为加载程序在本地查找之前会执行 GAC 搜索(在这种情况下是徒劳的)。

选择要么是强命名(因此需要引用来匹配精确的键和精确的版本)，要么是非强命名(并且不需要两者都匹配)，这似乎确实是一种耻辱。如果可以需要 key 但不需要特定版本，那么也许可以获得签名的前两个好处，而不会遇到第一个缺点。也许可以通过应用强名称然后使用 app.config 处理版本控制问题来实现？