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

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

应该给这些程序集起一个响亮的名字吗？

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

CA2210：使用强名称密钥签署。

然而，这个建议 http://msdn.microsoft.com/en-us/library/h4fa028b%28VS.100%29.aspx says:

一般来说，您应该避免使用强命名应用程序 EXE 程序集。

and

您可能希望避免使用应用程序私有的强命名组件。

我应该给这些程序集起一个响亮的名字吗？在这种情况下这样做（或不这样做）有什么好处？

Edit:

纵观几个具有相似结构的应用程序，在这个问题上似乎没有达成共识。的二进制文件画图网 http://www.getpaint.net/ and 破解网 http://www.codeplex.com/cracknetproject不是强名称，而.NET反射器 http://www.red-gate.com/products/reflector/ and Snoop http://blois.us/Snoop/ are.

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

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

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

Edit 2:

如果没有压倒性的理由采取任何一种方式，我倾向于给我的集会一个响亮的名字。因此，我对是否有人可以对此进行扩展感兴趣（从第一个链接）：

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

在我看来，在这种情况下强名签名的好处如下：

• 防止攻击者用使用另一密钥签名（或根本未签名）的 DLL 替换 DLL，而无需替换 EXE（因为 EXE 包含包含公钥的引用）。
• 防止攻击者在保留现有密钥的同时修改程序集（因为这将导致签名验证失败）。但请注意，从 .NET 3.5 SP1 开始，这种情况下的签名验证是默认禁用 http://blogs.msdn.com/shawnfa/archive/2008/05/14/strong-name-bypass.aspx.
• 可以防止应用程序使用不匹配版本的程序集运行 - 如果由于部署错误而错误地替换了 DLL，则应用程序将无法加载它，而不是尝试使用（可能不兼容的）错误版本。
• 避免 FxCop 警告。

以及签名的缺点（我相信这些是链接文章所指的）：

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

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