Declarative Security Used with Class and Member Scope
Declarative security can be performed on classes, members, and nested classes. This section outlines the rules used to evaluate declarative security when applied to multiple levels of the same class.
.gif "Important note") Important |
|---|
In the .NET Framework version 4, runtime support has been removed for enforcing the Deny, RequestMinimum, RequestOptional, and RequestRefuse permission requests. These requests should not be used in code that is based on .NET Framework 4 or later. For more information about this and other changes, see Security Changes in the .NET Framework 4. |
Classes, Members, and Declarative Security
When there is declarative security for the same security action on both the class level and the method level, the declarative security will be applied according to the following table.
Security action |
NET Framework version 2.0 behavior |
.NET Framework version 4 behavior |
|---|---|---|
Demand |
Method-level attributes and class-level attributes are unioned together into a single permission set for both levels. |
No change in behavior. |
Link demand |
Method-level attributes and class-level attributes are unioned. |
No change in behavior. |
Inheritance demand |
Class-level attributes require the specified permission in order to derive from the class. Method-level attributes require the specified permission in order to override the method in a derived class. Because inheritance demands have different meanings for classes and methods, declarations can be applied to both the class and method levels independently. |
No change in behavior. |
Assert |
Method-level attributes and class-level attributes are unioned together into a single permission set for both levels. |
No change in behavior. |
Deny |
Method-level attributes and class-level attributes are unioned together into a single permission set for both levels. |
Obsolete in the .NET Framework 4. |
Permit only |
Method-level attributes and class-level attributes are intersected together into a single permission set for both levels. |
No change in behavior. |
If the security actions are different (for example, a demand at class level with an assert at method level), there is no interaction whatsoever and both are evaluated.
Nested Classes and Declarative Security
When you apply declarative security to classes, it does not propagate to any nested classes or methods of nested classes. Conversely, when you apply declarative security to nested classes or methods of a nested class, it does not propagate to the parent classes either. You should apply declarative security to nested classes as if they were separate classes.
The following example shows a hypothetical permission demanded on the class level of a class called Main. Within that class, a nested class called Nested is defined. In this example, the demand does not apply to the nested class.
<SomePermissionAttribute(SecurityAction.Demand, Unrestricted:=True)> _
Public Class Main
' This nested class is not influenced by the demand.
Public Class Nested
' This method is not influenced by the demand.
Public Sub MyMethod()
End Sub
End Class
End Class
[SomePermissionAttribute(SecurityAction.Demand, Unrestricted = true)]
class Main
{
// This nested class is not influenced by the demand.
class Nested
{
// This method is not influenced by the demand.
public void MyMethod()
{
}
}
}