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

Question

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

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

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

CA2210：标志<装配>具有强名称键。

但是，此建议说：

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

和

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

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

编辑：

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

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

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

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

编辑 2：

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

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

Answer 1

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

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

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

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

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

Answer 2

强命名程序集仅确保版本兼容性。这与信任议会不同。

换句话说，“强名称”仅指确切的程序集二进制文件与编译时使用的版本号的组合。

如果您对这些程序集进行 GAC，那么 CLR 只会验证它一次。当时大会已开始。这可以提高性能。然而，我的经验表明它是最小的。

强命名的程序集可以替换为非强命名的程序集；这提出了关于强命名不是任何类型的安全功能的部分。

我个人的观点是，与它们相关的疼痛程度并不能证明它们的使用是合理的。痛苦在于他们如何使用自动化测试工具。

https:// web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-5054496.html

Answer 3

对程序集进行签名可确保程序集在编译后不会被修改。只要您是唯一的私钥所有者，就没有人能够使用您的密钥退出程序集。

当然，这并不是绝对的保护。黑客可以修改程序集并从所有程序集中删除强名称签名（和引用）。这些组件也可以工作。

但在这种情况下，您可以说修改不是由您进行的。

Answer 4

如果您对程序集进行签名，则任何引用的程序集都会公开公开，它们也必须进行签名。否则，您将有充分的理由得到编译错误。

我认为强命名程序集的主要用途是将其放入 GAC 中。

我认为没有必要对 exe 进行强命名。

只是我的2比索......