管理开源项目的强名密钥对的建议方式是什么？

Question

我管理一个开源项目，并想签署项目二进制包中发布的二进制文件。我使用Visual Studio csproj和sln文件来管理和构建我的项目，并将这些文件作为项目源代码包的一部分进行分发。

我该如何签署生成的二进制文件，而不必分发snk密钥对文件？如果我使用Visual Studio签署程序集，则每个项目文件现在都需要密钥对的副本才能构建。即使密码保护，我也不习惯分发密钥对。

编辑：

另一个需要注意的是，有些组件在通过InternalsVisibleToAttribute项目补助朋友访问，并通过项目建设参考那些朋友。因此，在引用签名程序集时，此类程序集需要使用强名称。但是，如果密钥对未分配，那么最终用户如何构建资源并维护项目关系？如果使用临时密钥对文件，那么签名程序集的公钥令牌是否会发生更改，从而破坏了引用？

Answer 1

Sharptooth's solution如果代码中的唯一程序集引用是在项目文件中编码的那些，则效果很好。如果您的项目通过InternalsVisibleToAttribute或其他需要使用强名称字符串的方式引用其他程序集，则使用临时密钥构建存储库源是不可行的。这样做会更改强名称字符串中存在的公钥引用并破坏代码。

这是我的应用程序中的情况，所以我需要采用不同的方法。

我基本上在单独的文件夹中创建了sln和csproj文件副本，并修改了csproj文件，如下所示。

• 转换所有文件引用链接，指向原始来源。
• 复制并修改每个AssemblyInfo.cs文件以包含具有强名称的InternalsVisibleToAttribute的用法。
• 改性每个csproj文件，以便snk文件参考是一个相对路径（去除到snk文件复制到每个项目的需要）

我首先手动做所有这一切，但随后意识到这可以以直接的方式自动化。第一步和第三步可以用XSLT来实现，其中第二步可以用正则表达式搜索/替换函数来实现。

由于我现在需要维护两种解决方案，因此将此任务自动化以避免未来的麻烦是有意义的。

存储库中的源代码不会使用强名称构建程序集，这很好，因为我不想在最终用户上施加任何构建限制或进程。

Answer 2

你不应该分配密钥对。强名称用于验证新版本的程序集来自同一个发布者。

如果另一个开发人员想要分支项目，他们将生成自己的密钥对，并且这将有效地显示他们的版本不是来自您的，所以依赖于您的其他程序集将不会再加载，除非它们被重新编译。这并不总是方便，但它可以保护您免受发布恶意版本的程序集并以静默方式分发它的用户。