Declarative and Imperative Style

The CLR allows developers to express security constraints in two styles: declarative and imperative. Expressing security constraints in the declarative style means using the attribute syntax. These annotations are persisted in the metadata for the type, effectively becoming baked into the assembly at compile time. The following is an example of declarative-style security from Listing 4.4:

 [PrincipalPermissionAttribute(SecurityAction.Demand,                       Name=@" PROJECT42\Damien Watkins ")] 

Expressing security requirements in the imperative style entails creating instances of Permission objects at runtime and invoking methods on them. The following is an example of imperative-style security from Listing 4.7:

 FileIOPermission p = new FileIOPermission(                     FileIOPermissionAccess.Write, f); p.Demand(); 

There are a few reasons for choosing one style over the other. For instance, all security requirements can be expressed using the declarative style; the same is not true for the imperative style. However, the declarative style requires that all security constraints be expressed at compile time; the imperative style is more flexible because it allows constraints to be expressed at runtime.

A side effect of persisting declarative security requirements in the metadata is that you can use tools to extract this metadata information and then provide functionality based on this fact. For example, a tool may display a list of the declarative security attributes set on an assembly. This feature is not available with imperative security. Developers need to be aware and fluent with both styles.