Creating Other Custom Permissions
If you need to create a permission to protect a resource, but you do not want a demand for your custom permission to cause a stack walk, you should create a permission that implements IPermission but does not derive from CodeAccessPermission. One example of a scenario in which this makes sense is a bank application that needs to restrict the ability of code to perform transactions, but for which you do not want the permissions of all callers in the stack to be checked to determine whether they are authorized to perform the transaction. Instead, you want authorization to be based on whether the current time of day falls within a specified range. This situation requires a custom permission object that is not a custom code access permission.
The requirements for this kind of permission are very similar to those for a custom code access permission. You must perform the following steps in order to use such a permission:
Implement IPermission.
Implement ISecurityEncodable to add support for XML encoding and decoding.
Support declarative security by defining an attribute.
Demand your custom permission within a library.
Note that security policy does not have to be updated to include non-code access permissions. You do not have to use the Code Access Security Policy Tool (Caspol.exe) or the .NET Framework Configuration tool (Mscorcfg.msc) to adjust security policy when using such a hypothetical permission.
See Also
Concepts
Creating Your Own Code Access Permissions
Adding Declarative Security Support
Reference
Code Access Security Policy Tool (Caspol.exe)
.NET Framework Configuration Tool (Mscorcfg.msc)