在某些情况下,您可能需要对程序集进行强命名-更多关于强命名以及您可能需要它的原因
然而,强命名您的程序集可能会给您的开发过程带来一些不便。要强命名程序集,您需要在构建期间访问公钥和私钥。
像StrongNamer这样的工具对您的 3rd 方未签名依赖项有很大帮助。有助于解决强命名的病毒性特征。
在某些情况下,您只希望组织中的少数人(企业和 OSS 中不太可能,但仍有可能)访问私钥以验证程序集的身份。
在那些您不想公开(即在 GitHub OSS 中)或与整个开发团队(企业上下文)共享私钥的场景中,但您也不想在公开签名之前打扰开发过程(引入在 VS 2015 Update 2 编译器中)您只有一种选择 -延迟对您的程序集进行签名。
在您重视私钥(最终是程序集身份)的情况下,延迟签署您的程序集仍然会在开发过程中引入一些摩擦。每个需要构建和运行它的人都必须注册这个程序集,以便在运行时跳过程序集验证(使用具有管理员权限的“sn –Vr myAssembly.dll”命令)。
进入公共签名方法。它似乎是延迟签名方法的替代方案。因此,公开签署程序集与延迟签署程序集相同,但您的开发团队不需要在他们的机器上执行“sn –Vr myAssembly.dll”命令。但是,它有一些限制:
在 .NET Framework 上调试和测试公共签名程序集时的已知问题:
- 您将无法将程序集安装到全局程序集缓存 (GAC)
- 您将无法在启用了卷影复制的 AppDomain 中加载程序集
- 您将无法在部分受信任的 AppDomain 中加载程序集
*关于程序集标识的注意事项:强命名用于程序集标识而不是安全性。强命名(完全签名)程序集将经受验证检查(即“sn -vf myAssembly.dll”),这将验证程序集及其所有内容是否与签名时一样。
不是安全问题,因为至少在某些上下文中绕过运行时程序集加载特定程序集的强名称验证相当容易。
| 归档时间: |
|
| 查看次数: |
399 次 |
| 最近记录: |