系统提供了八种内置成员条件类型。AllMembershipCondition的Check方法总是返回true，而与证据（被用于每个策略级别的根代码组）无关。ApplicationDirectoryMembershipCondition的Check方法用于检查一个可疑程序集是否是从应用程序目录加载的。这种成员条件使用URL证据决定程序集的基本代码(code base)，并依赖一个宿主提供的证据中所指定的ApplicationDirectory证据对象。这个证据必须由宿主应用程序所创建，例如ASP.NET。余下的六种成员条件类型（例如，UrlMembershipCondition、ZoneMembershipCondition等等）直接对应于六种宿主证据类型（例如，Url、Zone等等），允许通过特定的证据来决定成员资格。

为了允许将一个以上的权限集应用到特定的程序集上，代码组是分层的。可以包含于代码组。这些子代码组通过CodeGroup.Childran属性可见。出现在安全策略中的大多数代码组，都是System.Security.Policy.UnionCodeGroup类型的实例；如果成员条件满足的话，UnionCodeGroup将列举出所有的子代码组，并将成员条件也满足的每个子代码组的权限集合并起来,因为子代码组自身可能也有子级，所以这个过程将可能导致评估大量的权限集。不过如果一个给定的代码组的成员条件不满足，则它的任阿子级将不予考虑。例如，考虑图9.3所展示的代码组层次结构。然而，假如代码组A的成员条件不满足，那么其他代码组都将不予考虑（结果权限集将为空）。如果代码组A的成员条件满足了，那么组B、C、G、H、I和N将被考虑。如果代码组C的成员条件满足，那么组D和E也就会予以考虑。


你可以在一个代码组上设置两个属性，从而修改它的解释过程，PolicyStatementAttribute.Exclusive属性表明，没有其他的兄弟代码组可以和这个代码组联合在一起。在先前的例子中，如果这个特性设置于B组上，那么若B组的成员条件满足，则组C、G、H、I和N将不予考虑。在一个给定的层次结构的一层中，如果提供的证据与多于一个的排他组匹配，将被认为是一个策略错误，你可以改变代码组解释过程的第二个属性
PolicySatatementAttribute.LevelFinal。这个属性通知安全管理者，对于较低的策略级别不予理睬。例如，如果把这个特性设置于SecurityLevel.Machine策略级别的一个匹配代码组上,SecurityLevelUser和SecurityLevel.AppDomain策略级别都将被忽略。这防止了因为疏忽对它们授予必需的权限，而使得具有较低权限的用户和系统管理员无法使用关键性的组件。

将证据体解析到一个匹配的代码组集合的能力，是通过CodeGroup.ResolveMatchingCodeGroups方法公开的。这个方法对当前代码组及其所有子级执行成员条件检验，以决定哪些代码组匹配。作为一种便利PolicyLevel类型有一个ResolveMatchingCodeGroups方法，当确定该策略级别实际上已被加载后，它只是简单地将调用转发给根代码组：

为了跨越所有可适用的策略级别而查找匹配的代码组，你可以调用SecurityManager.ResolvePolicyGroups静态方法。这个静态方法只是对策略层次结构中的每一个策略级别（例如，“计算机”或“企业”）分别调用PolicyLevel.ResolveMatchingCodeGroups。下面示例中展示的C#程序，使用SecurityMarager.ResolvePolicyCroups来列举所有的代码组—给定的程序集是这些代码组的成员：


SecurityManager.ResolvePolicyGroups方法有些局限，因为只有当你知道代码组从哪个策略级别而来时，结果代码组里的权限集名字才有意义,有幸的是，有几个高阶方法同样能够解析权限集，这些方法将在本章后面讨论。o