AssemblyDelaySignAttribute类在 .NET 中提供了一种机制，允许开发者在编译时为程序集预留强名称签名的空间，但将实际的私钥签名过程推迟到发布前或交付给安全团队时进行。这对于在没有私钥访问权限的环境中进行开发和测试非常有用，因为它分离了构建和最终签名的职责。
解决方案
延迟签名，听起来有点玄乎，但它解决了实际开发中的一个痛点：你可能在开发阶段没有权限接触到那个至关重要的私钥。想象一下，你的团队在开发一个内部组件，它需要强名称，但私钥由安全部门严格保管。每次构建都得找他们签名？那效率简直是灾难。
AssemblyDelaySignAttribute就是来解决这个问题的。它的核心思想是：你先用一个公钥来“占位”，告诉 CLR 这个程序集未来会有一个强名称签名。编译的时候，编译器会检查公钥，并为最终的签名预留空间。但它并不会真正用私钥去加密哈希，所以你不需要私钥就能编译通过。
具体操作流程大概是这样：
生成密钥对： 首先，你需要一个强名称密钥对。通常用
sn.exe工具来生成：
sn.exe -k MyKeyPair.snk
提取公钥： 从生成的密钥对中提取公钥，这样你就可以在开发环境中使用它，而无需私钥：
sn.exe -p MyKeyPair.snk MyPublicKey.snk
在代码中应用属性： 在你的
AssemblyInfo.cs（或项目文件中的全局 using）里，添加这两个属性：
// 告诉编译器这个程序集需要延迟签名
[assembly: System.Reflection.AssemblyDelaySign(true)]
// 指定用于延迟签名的公钥文件
[assembly: System.Reflection.AssemblyKeyFile("MyPublicKey.snk")]
// 或者，如果你想直接嵌入公钥，可以使用AssemblyKeyName，但这通常用于更复杂的场景
// [assembly: System.Reflection.AssemblyKeyName("MyPublicKeyContainer")]注意，
AssemblyKeyFile指向的是你提取出来的公钥文件，而不是完整的密钥对文件。
编译项目： 正常编译你的项目。此时，程序集会包含公钥信息，并且为签名预留了空间，但它实际上并没有被完全签名。如果你尝试在未注册强名称的 GAC 中引用它，可能会遇到问题，因为 CLR 会认为它没有完整的强名称。
禁用强名称验证（可选，但开发时常用）： 在开发或测试环境中，你可能需要暂时禁用对这个延迟签名程序集的强名称验证。这可以用
sn.exe来完成：
sn.exe -Vr YourAssembly.dll这个命令告诉 CLR，对于
YourAssembly.dll，即使它没有完全签名，也暂时不要进行强名称验证。这在调试和测试阶段非常有用。
最终签名： 当你的程序集准备好发布时，或者在 CI/CD 流程的后期，你需要用完整的密钥对来对其进行最终签名。这通常也是用
sn.exe完成的：
sn.exe -R YourAssembly.dll MyKeyPair.snk这个命令会用
MyKeyPair.snk中的私钥对
YourAssembly.dll进行真正的签名，使其成为一个完全强名称签名的程序集。
通过这种方式，开发团队可以在不接触私钥的情况下进行开发、构建和初步测试，只有在最终发布前才进行一次真正的、由授权方执行的签名操作。这大大简化了工作流程，提高了安全性。
为什么我们需要延迟签名，它解决了哪些痛点？
说实话，第一次接触“延迟签名”这个概念时，我脑子里冒出的第一个问题就是：这玩意儿有啥用？直接签名不香吗？但随着项目规模的扩大，以及团队协作模式的变化，它的价值就凸显出来了。
最核心的痛点在于私钥的保管和访问权限。在一个稍微正规点的公司里，用于强名称签名的私钥，那可是“国家宝藏”级别的存在。它通常由专门的安全团队保管，访问权限极其严格。如果每次开发构建都需要这个私钥，那开发人员就得频繁地去申请、去协调，这无疑是巨大的摩擦成本。想象一下，一个大型项目，几十个开发者，每天编译几十上百次，每次都要私钥，这简直是噩梦。延迟签名就像是给开发团队发了一张“临时通行证”，让他们可以先进入“施工现场”进行工作，等工程快完工了，再由“安保部门”拿着“正式许可证”来盖章。
其次，它优化了 CI/CD 流程。在自动化构建和部署的环境中，我们不希望构建服务器上存放敏感的私钥。通过延迟签名，构建服务器可以只使用公钥进行编译，生成“半成品”的程序集。而真正的签名步骤可以放到更安全、更受控的发布服务器上进行，或者作为部署流水线中的一个独立、受限的步骤。这极大地提升了 DevOps 的安全性。
还有一点，就是组件的发布和引用。如果你开发的组件需要被其他强名称签名的程序集引用，那么你自己的组件也必须是强名称签名的。但在开发初期，你可能还没决定最终的强名称密钥，或者像前面说的，没有私钥。延迟签名让你能够提前满足强名称的要求，而不用等到私钥到位才开始组件间的引用和集成测试。它提供了一种灵活的“契约”机制：我承诺未来会有一个强名称，你现在就可以相信我。
当然，它也不是万能药，比如在开发阶段，如果你的延迟签名程序集需要被一个已完全签名的程序集引用，那在调试时你可能就需要禁用强名称验证。这本身也算是一种“妥协”，但相比于每次构建都去要私钥，这代价小多了。总的来说，延迟签名是一种权衡，它在安全性和开发效率之间找到了一个不错的平衡点。
延迟签名与完全签名有什么区别，对程序集有何影响？
延迟签名和完全签名，就像是画了一幅草图和完成了一幅油画。
延迟签名 (Delay Signing)： 当一个程序集被延迟签名时，它在编译阶段就包含了强名称公钥信息，并且在程序集文件中预留了用于完整签名的空间。但是，这个空间并没有被私钥加密的哈希值填充。所以，从技术上讲，它不是一个“完整”的强名称签名的程序集。
特点： 公钥存在： 程序集清单中包含公钥。 无私钥加密： 没有私钥对程序集哈希进行加密。 可编译和引用： 可以在开发环境中编译通过，并且可以被其他程序集引用（前提是引用方也知道它会是强名称，或者禁用了强名称验证）。 不完全受信任： 默认情况下，CLR 不会完全信任一个延迟签名的程序集，因为它的完整性尚未被私钥验证。如果尝试将其安装到全局程序集缓存（GAC），通常会失败，因为它不满足 GAC 对强名称的严格要求。 文件大小： 可能会比未签名的略大一点点，因为预留了签名空间。完全签名 (Full Signing)： 当一个程序集被完全签名时，它不仅包含了强名称公钥，而且程序集的哈希值已经被对应的私钥加密，并将这个加密后的哈希值（即数字签名）嵌入到了程序集文件中。这是一个完整的、经过加密验证的强名称程序集。
特点： 公钥和私钥加密签名： 包含公钥，并且有私钥加密的完整数字签名。 完整性验证： CLR 在加载时可以验证其完整性，确保程序集自签名后未被篡改。 可安装到 GAC： 满足安装到 GAC 的所有条件。 完全受信任： 被 CLR 完全信任，适用于安全敏感的环境和跨应用程序域共享。 不可篡改： 一旦签名完成，任何对程序集内容的修改都会导致签名失效，CLR 会拒绝加载。对程序集的影响：
-
加载和验证： 延迟签名的程序集在加载时，CLR 会识别出它是一个延迟签名的程序集。如果没有禁用强名称验证，加载可能会失败。而完全签名的程序集则会进行完整的强名称验证。
GAC 安装： 延迟签名的程序集不能直接安装到 GAC，除非你对 GAC 所在机器禁用了它的强名称验证。完全签名的程序集则可以。
引用链： 如果你有一个完全签名的 A 程序集，它引用了一个延迟签名的 B 程序集，那么在运行时，如果 B 没有被最终签名或者没有禁用验证，A 的加载可能会失败。这是因为强名称是具有传递性的：一个强名称程序集只能引用其他强名称程序集。
安全性： 延迟签名在开发阶段提供便利，但在生产环境中，它必须被最终签名才能提供完整的安全性和完整性保证。未最终
