SecurityAttribute和CodeAccessSecurityAttribute有什么区别？

Question

在创建自定义安全属性（在我的情况下声明性地要求自定义权限）时，继承SecurityAttribute或CodeAccessSecurityAttribute有什么实际区别？

反映类型，CodeAccessSecurityAttribute似乎没有以任何有意义的方式扩展SecurityAttribute，所以我只能假设CAS系统使用该类型，但是这个代码被烘焙到CLR中，所以我无法读到它。

自定义权限的所有示例都从CodeAccessSecurityAttribute继承，但没有解释原因。实际上，PrincipalPermissionAttribute继承自CodeAccsesSecurityAttribute，尽管不是严格的CAS相关权限（因为它具有不同的语义并引用当前主体，而不是授予调用程序集的权限）。

我的问题是学术问题 - 我可以从CodeAccessSecurityAttribute继承进步 - 但我想知道原因！

Answer 1

我不建议使用这些属性。它们的功能太复杂了，微软自己也承认了这一点。例如。对于Silverlight，它们已经过时了：System.Security.Permissions (Silverlight)

Answer 2

您认为CLR本身使用CodeAccessSecurityAttribute类型是正确的。这实际上是CLR提供的AOP样式行为，它将在运行时验证（和/或修改）CodeAccessSecurityAttribute子类型实例创建的权限。您不能将SecurityAttribute用于基类的原因是CLR仅扫描CodeAccessSecurityAttribute个子类型。它将忽略SecurityAttribute的其他子类型。

至于为什么会出现这种情况，我不知道任何公开的文档。但是，似乎可以安全地假设它可能只是.NET开发历史中不幸的副产品。很容易想象在.NET 1.0的设计/开发周期中引入非CAS权限的情况，并且对这些权限的支持使其成为BCL但不进入CLR。鉴于实际创建非CAS权限的开发人员数量很少，“修复”CLR权限属性检测器可能从未被认为足够重要，值得任何后续.NET发布周期中的任何认真关注。