开源项目的二进制文件签名

Question

我尝试在我的当前项目中使用ServiceStack，但发现发布的二进制文件没有强名称，所以我不能直接使用它。当在GitHub上询问“为什么”时，我得到了以下答复：“它会传染毒瘤，阻碍绑定、升级、开发、部署等。”mythz非常简洁，所以我不想再麻烦他了，所以来这里问。我使用很多开源.NET项目，如AutoMapper，NUnit，Moq，log4net，Ninject等，它们的发布版本都是有强名称的。在SO上找到了类似的问题，但对我没有帮助。这是OSS中的正常做法吗？为什么不同时发布已签名和未签名的二进制文件？

- UserControl

Answer 1

以下是有关为什么强名称对于开源项目不是一个好主意的现有讨论：

https://groups.google.com/forum/?fromgroups#!topic/getglimpse-dev/pXXazMOOdjE

Here is a nightmare story from using it:

http://haacked.com/archive/2012/02/16/changing-a-strong-name-is-a-major-breaking-change.aspx

我曾经参与过两个团队，他们在同一个项目中尝试使用引用了两个不同版本的Log4Net强命名程序集，经历了两代Log4Net的煎熬。浪费大量时间和精力来使其工作并不好玩，我们也不打算让自己或所有用户都遭受这种折磨。

想要强命名版本的用户可以自由地签署自己的公共ServiceStack repos克隆/分支。

如果有需求，我们将考虑维护我们自己的“官方签名”商业版本的库。

- mythz

---

谢谢提供的链接，非常有趣，但我必须指出这些人混淆了签名和版本控制——这是两个不同的概念！虽然在.NET世界中，签名是强名称的一部分，但在发布新版本时并不需要更改版本号（例如log4net版本方案；相反，他们可以使用文件版本控制，并保持IL版本相同）。我认为发布未签名的二进制文件、用相同的IL版本签名和用增加的IL版本签名都没有问题。有多种选择让所有人都满意，所以当您重新考虑维护“官方签名”二进制文件时，这是我的+1。 - UserControl

您无法对具有非强名称依赖项的程序集进行“authenicode”签名。就个人而言，没有轻松访问强名称程序集会是一场噩梦，并且严重阻碍部署。 - Robin

我知道我来晚了，但我真的不明白在签名程序集方面有什么问题。如果您一直使用相同的密钥，那么签名会有什么问题呢？程序集重定向难道不能解决版本问题吗？ - dabide

请注意，“噩梦故事”是关于在不增加主版本或次版本号的情况下更改强名称密钥对，从而导致与NuGet的版本控制问题。据我所知，NuGet默认采用相同主版本.次版本的最新构建版本。 - Lucero

我也来晚了，但我不认为有任何动机去强命名程序集，特别是开源的。它们只在安装到GAC时有用，所以简单的解决方案就是永远不要使用GAC。我从未遇到过这种策略的问题，而我却一直遇到强命名文件的无尽问题。我希望每个人都停止签名。 - Miral

Answer 2

我认为这取决于开发者。优点很明显 - 任何人都可以使用带有强名称的程序集，在任何环境中使用它。在这种情况下，我指的是签名或未签名程序集。缺点 - ？

我认为签署二进制文件应该是一种绅士规则。

Jon Skeet在类似的问题上进行了回答，并且他的观点非常易懂。 链接

- Sergio Rykov