[FxCop.设计规则]2. 程序集应该拥有一个有效的强名称
2005-05-24 21:32
363 查看
2. 程序集应该拥有一个有效的强名称
原文引用:
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(全局程序集缓存)
如果需要分析一个延迟签名的程序集,必须禁用这条规则。
修复:
使用强名称工具生成Key文件,并用这个文件签名程序集。你可以使用下面的一种方法签名这个程序集:1. 使用.NET Framework SDK中的程序集连接工具(Al.exe)
2. 在.NET Framework v1.0或v1.1中,使用System.Reflection.AssemblyKeyFileAttribute或System.Reflection.AssemblyKeyNameAttribute属性标记程序集。
3. 在.NET Framework v2.0中,使用/keyfile或者/keycontainer编译指令。(在C++中,使用/KEYFILE or /KEYCONTAINER连接指令)
相关文章推荐
- [FxCop.设计规则]2. 程序集应该拥有一个有效的强名称
- [FxCop.设计规则]2. 程序集应该拥有有效的强命名
- 程序集应该拥有一个有效的强名称
- 关于“Assemblies Should Have Valid Strong Names 程序集应该拥有一个有效的强名称”的分析与解决
- 关于“Assemblies Should Have Valid Strong Names 程序集应该拥有一个有效的强名称”的分析与解决 转
- [FxCop.设计规则]1. 抽象类不应该拥有构造函数
- [FxCop.设计规则]1. 抽象类不应该拥有构造函数
- [FxCop.设计规则]7. 集合类应该实现泛型接口
- [FxCop.设计规则]8. 也许参数类型应该是基类型
- [FxCop.设计规则]8. 也许参数类型应该是基类型
- C++设计的又一个缺陷——构造函数与析构函数名称不应该用类名
- [FxCop.设计规则]10. 类型应该被声明在命名空间中
- [FxCop.设计规则]10. 类型应该被声明在命名空间中
- [FxCop.设计规则]11. 不应该使用默认参数
- [FxCop.设计规则]11. 不应该使用默认参数
- 软件开发中设计为什么应该只有一个所有人?
- 阿里云前端周刊 - 第 29 期 RESTful API 设计最佳实践_项目资源的URL应该如何设计?用名词复数还是用名词单数?一个资源需要多少个URL?
- Error occurred in deployment step 'Add Solution': 此解决方案包含面向全局程序集缓存的一个或多个程序集。您应该为将保存在全局程序集缓存中的任何程序集使用
- pads规则(对某一个元件单独设计规则)
- 编写一个程序,设计一个Cdate类,它应该满足下面的条件:(1).用这样的格式输出日期:日-月-年;(2).输出在当前日期上加两天后的日期;