强名称/签名程序集的优点/缺点答案

【问题标题】：Pros/Cons of strong-named/signed assemblies强名称/签名程序集的优点/缺点
【发布时间】：2011-04-07 15:16:16
【问题描述】：

我们有一个包含许多项目的解决方案（可能有 20 个或更多）。最近我们进行了一些更改，要求其中一些程序集可以从 COM 调用，这意味着我们需要对它们进行强命名。这些程序集引用了我们项目中的其他程序集，这意味着它们也需要强命名。它们还具有 InternalsVisibleTo 属性，因此授予的程序集也必须是强命名的。

我建议我们简单地对它们都进行强命名，而不是试图找出哪些程序集需要签名/强命名。这让一些人对风险感到头晕目眩。我认为没有风险，但他们想要签署程序集的利弊。我能想到的唯一事情是：

优点

需要调用来自 COM 的程序集
它将允许我们将程序集放入 GAC（我们现在不要这样做）
它可以防止篡改（我们托管应用程序，它没有安装在客户网站上，所以问题不大）

缺点

它要求我们将来使用的每个程序集都进行签名

我有两个具体问题：

您认为一般情况下签署/强名称程序集是个好主意吗？
您能想到其他优点或缺点吗？

【问题讨论】：

现在必须签署所有内容的想法从何而来？病毒式的是未签名的程序集：您不能从已签名的程序集中引用未签名的程序集。你可以做相反的事情。必须签名的那些是由于您在第一段中概述的原因。
顺便说一句：它不会停止篡改。您可以剥离 SN，并更改引用程序集，一切顺利。我这样做是为了对一些使用 Reflector 和 Reflexil 的商业软件进行概念验证
@David：你甚至可以单独使用 ilasm 和 ildasm 来完成。 @Future David：谢谢，我切换了签名/未签名的顺序。
@Martino 我认为你把最后一部分搞混了——你不能从已签名的程序集中引用未签名的程序集，但你可以从未签名的程序集中引用已签名的程序集。
我从来没有说过我们解决方案中的所有内容必须签名。我的观点是，与其寻找和啄以确定哪些必须签名，不如将它们全部签名更简单。它还可以避免将来出现问题，即开发人员将已签名项目的引用设置为未签名项目，然后解决方案突然无法编译，因为现在我们必须签署新引用的项目并查找所有内容 it 引用以确保它们已签名。

标签： .net assembly-signing

【解决方案1】：

你的单身骗局是假的。它实际上是专业人士。

未签名的程序集可以专门由未签名的程序集使用。已签名程序集和未签名程序集均可使用已签名程序集。

【讨论】：

我碰巧认为它也是专业的，但客观地说，这确实意味着我们从现在开始带入组织的任何软件（商业、开源、共享软件等）都必须提供签名版本或我们必须能够使用我们自己的 snk 构建签名版本。我认为从业务的角度来看，这可能被视为一个骗局。
@Craig：这是一个有效的观点。我正在考虑与负责任的供应商合作的理想情况:(。遗憾的是，并非所有制作可重用软件的人都在不加思索的情况下签署他们发布的内容：这是让所有客户满意的唯一方法。

【解决方案2】：

“需要从 COM 调用程序集”

您无需对程序集进行签名即可使其成为 COM 组件。我在没有签署程序集的情况下实现了很多 COM-server。

还有一些缺点：

如果不替换所有其他需要它的程序集，就无法用新版本更新程序集 => 轻松共享组件
不能使用未签名的第三方组件（许多免费/开源）
GAC 中签名的程序集未经验证，邪恶的人可以用任何东西更改/替换您的签名程序集，您的程序很乐意接受这个任何东西link

【讨论】：

“你不能在不替换所有其他需要它的程序集的情况下用新版本更新程序集 => 轻松共享组件”不是真的。您必须在配置中添加一行以进行绑定重定向。这可能仍然是一个骗局，但不是灾难性的。
您必须将它添加到每个使用该组件的应用程序中。如果你有 app->module->component 并且你更新了组件，那么应用程序必须为它甚至不知道的组件添加重定向。合并到模块中的实用程序 dll 的常见场景
“如果不替换所有其他需要它的程序集，你就不能用新版本更新程序集”你应该告诉微软，因为他们已经这样做了很长时间了。
@Voo 您只能更改具有相同版本和公钥的文件。我“享受”了使用相同版本演化库的乐趣，因为依赖程序集不再加载它。 MS 仅以这种方式提供内部错误修复。
和更改 mashine.config 以重定向到较新版本会带来麻烦。

【解决方案3】：

ClickOnce 要求对您的程序集进行签名
许多开源项目不分发签名的程序集，并且使用您自己的 SNK 编译通常很重要

【讨论】：

合并为 1 个答案。感谢社区对此的反馈。
+1 用于提及未签名的发行版。当您必须安装东西才能运行开源项目的构建脚本时，这很麻烦，因为开发人员听到了一些关于签署程序集的 FUD 并感到害怕。
我们已经考虑了开源问题。我们公司不愿意采用开源解决方案，我们使用的少数解决方案要么提供了签名的程序集，要么非常简单地构建了签名版本。