[FxCop.设计规则]2. 程序集应该拥有有效的强命名
2006-06-06 10:18
211 查看
版权声明: 本文由timewolf完成,首发于CSDN,作者保留版权。 未经许可,不得使用于任何商业用途。 欢迎转载,但请保持文章及版权声明完整。 如需联络请发邮件:karla9(AT)eyou(dot)com |
原文引用:
Assemblies should have valid strong names
Rule Description This rule retrieves and verifies the strong name of an assembly. A violation occurs if any of the following are true: The assembly does not have a strong name. The assembly was altered after signing. The assembly is delay-signed. The assembly was incorrectly signed, or signing failed. The assembly requires registry settings to pass verification. For example, the Strong Name tool (Sn.exe) was used to skip verification for the assembly. The strong name protects clients from unknowingly loading an assembly that has been tampered with. Assemblies without strong names should not be deployed outside of very limited scenarios. If you share or distribute assemblies that are not correctly signed, the assembly can be tampered with, the common language runtime might not load the assembly, or the user might have to disable verification on his or her computer. An assembly without a strong name suffers from the following drawbacks: Its origins cannot be verified. The common language runtime cannot warn users if the contents of the assembly have been altered. It cannot be loaded into the global assembly cache. Note that to load and analyze a delay-signed assembly, you must disable verification for the assembly. How to Fix Violations To fix a violation of this rule, use the Strong Name tool (sn.exe) to create a key file and sign the assembly with a strong name using one of the following procedures: Use the Assembly Linker tool (Al.exe) provided by the .NET Framework SDK. For the .NET Framework v1.0 or v1.1, use either the System.Reflection.AssemblyKeyFileAttribute or System.Reflection.AssemblyKeyNameAttribute attribute. For the .NET Framework version 2.0, use either the /keyfile or /keycontainer compiler option (/KEYFILE or /KEYCONTAINER linker option in C++). When to Exclude Messages Only exclude a message from this rule if the assembly is used in an environment where tampering with the contents is not a concern. |
引发原因:
1. 程序集没有使用强命名进行签名2. 强命名不能被校验
3. 程序集的强命名依赖于当前计算机的设置才有效。
规则描述:
这个规则读取并校验一个程序集的强命名,下面任何一条都会引起这条规则校验失败:1. 程序集没有进行强命名签名
2. 进行签名后,程序集被修改过。
3. 程序集被设置成延迟签名
4. 程序集签名失败
5. 程序集需要一定的注册表设置才能通过强命名校验
例如:通过强命名工具(Sn.exe)设置跳过对这个程序集的强命名校验
强命名保护用户不会使用一个被篡改的程序集。一个没有强命名的程序集只能被使用在非常小的范围内。如果你部署一个没有进行正确签名的程序集,程序集就有可能会被肆意篡改,以至于CLR可能会拒绝载入该程序集。在此情况下,用户就不得不将他的计算机设置为忽略强命名校验。
没有强命名的程序集有如下缺点:
1. 程序集的来源将不能被保证
2. 用户无从得知程序集是否被篡改过
3. 程序集不能被载入GAC(全局程序集缓存)
注意:如果需要分析一个延迟签名的程序集,必须禁用这条规则。
修复问题:
使用强名称工具(sn.exe)生成Key文件,并用这个文件签名程序集。你可以使用下面的一种方法签名这个程序集:1. 使用.NET Framework SDK中的程序集连接工具(Al.exe)
2. 在.NET Framework v1.0或v1.1中,使用System.Reflection.AssemblyKeyFileAttribute或System.Reflection.AssemblyKeyNameAttribute特性(Attribute)标记程序集。
3. 在.NET Framework v2.0中,使用/keyfile或者/keycontainer编译指令。(在C++中,使用/KEYFILE or /KEYCONTAINER连接指令)
可否忽略:
只有当用户(或开发者)不在意程序集是否会被篡改的时候,可以忽略该规则引发的警告相关文章推荐
- [FxCop.设计规则]2. 程序集应该拥有一个有效的强名称
- [FxCop.设计规则]2. 程序集应该拥有一个有效的强名称
- [FxCop.设计规则]10. 类型应该被声明在命名空间中
- [FxCop.设计规则]1. 抽象类不应该拥有构造函数
- [FxCop.设计规则]10. 类型应该被声明在命名空间中
- [FxCop.设计规则]1. 抽象类不应该拥有构造函数
- [FxCop.设计规则]7. 集合类应该实现泛型接口
- 程序集应该拥有一个有效的强名称
- [FxCop.设计规则]8. 也许参数类型应该是基类型
- [FxCop.设计规则]8. 也许参数类型应该是基类型
- [FxCop.设计规则]5. 避免命名空间中包含太少的类型
- 关于“Assemblies Should Have Valid Strong Names 程序集应该拥有一个有效的强名称”的分析与解决 转
- [FxCop.设计规则]11. 不应该使用默认参数
- 关于“Assemblies Should Have Valid Strong Names 程序集应该拥有一个有效的强名称”的分析与解决
- [FXCOP.设计规则]5. 避免命名空间中包含太少的类型
- [FxCop.设计规则]5. 避免命名空间中包含太少的类型
- [FxCop.设计规则]11. 不应该使用默认参数
- FxCop 设计规则
- FxCop 设计规则
- 你应该知道的应用UI动态设计规则