ama*_*eur 7 c# strongname assemblies snk .net-assembly
我目前正在设置我的.net库,使用强类型键进行签名.我正在使用.snk文件在每个解决方案的基础上签署我的dll.因此,对于每个解决方案,它都有自己的.snk文件.这是正确的做法吗？例如,我有一个类库,它从解决方案中的每个项目输出几个不同的dll,每个都使用.snk键进行签名.
我的问题围绕着源控件中密钥的存储.当我为每个版本分支我的代码时.应该关键:
A.存在于分支之外而不是分支 - 确保每个分支的相同密钥B.存在于分支内但对于每个分支是相同的C.存在于分支内并且针对每个分支进行更改D.其他(请注明)
建议好吗？
也可以通过将以下内容放在SolutionInfo文件中来签署dll,或者有其他选择吗？
[assembly: AssemblyKeyFile("<<absolute path>>\\MyKey.snk")]
根据您的具体实现，最佳实践通常是将 .snk 密钥文件保留在您正在处理的分支中。
用例是：我们正在 v1.0 和 v2.0 之间更改程序集签名密钥。您仍然希望能够在主干中维护当前代码，同时根据分支中的正确密钥进行开发。
其次，（这只是最佳实践，没有必要，具体取决于您的情况 - 例如您对其他开发人员的信任程度）您保留在源代码管理中的 .snk 文件应该只包含公钥，并且应该配置解决方案仅延迟签名。
这可以防止您的私钥传播，私钥应受保护地存储在构建服务器上（最有可能在 Windows 密钥管理器中），并在“发布”构建期间使用以完全签署程序集。如果您没有构建服务器，最好的做法是让 1 或 2 个人委托私钥，这样他们就可以在构建后使用 sn.exe 对程序集进行签名。一个简单的 shell 脚本或批处理文件可以自动执行此过程。
sn.exe -Vr *,<publicKeyToken>最后，仅当您选择延迟签名时，您才需要在所有将运行/调试延迟签名程序集的开发人员工作站上的.NET 程序集验证列表 ( ) 中添加一个条目。根据平台目标，您需要在 32 位和 64 位版本的 VS 命令提示符中运行它。
希望有帮助。