Code Access Security Basics
Every application that targets the common language runtime (that is, every managed application) must interact with the runtime's security system. When a managed application is loaded, its host automatically grants it a set of permissions. These permissions are determined by the host's local security settings or by the sandbox the application is in. Depending on these permissions, the application either runs properly or generates a security exception.
The default host for desktop applications allows code to run in full trust. Therefore, if your application targets the desktop, it has an unrestricted permission set. Other hosts or sandboxes provide a limited permission set for applications. Because the permission set can change from host to host, you must design your application to use only the permissions that your target host allows
You must be familiar with the following code access security concepts in order to write effective applications that target the common language runtime:
Writing type-safe code: To enable code to benefit from code access security, you must use a compiler that generates verifiably type-safe code. For more information, see Writing Verifiably Type-Safe Code.
Imperative and declarative syntax: Interaction with the runtime security system is performed using imperative and declarative security calls. Declarative calls are performed using attributes; imperative calls are performed using new instances of classes within your code. Some calls can be performed only imperatively, others can be performed only declaratively, and some calls can be performed in either manner. For more information, see Security Syntax.
Using secure class libraries: Class libraries use code access security to specify the permissions they require in order to be accessed. You should be aware of the permissions required to access any library that your code uses.
Transparent code: In the .NET Framework version 4 and later, in addition to identifying specific permissions, you must also determine whether your code should run as security-transparent. Security-transparent code cannot call types or members that are identified as security-critical. This rule applies to full-trust applications as well as partially trusted applications. For more information, see Using Secure Class Libraries and Security-Transparent Code.
See Also
Concepts
Writing Verifiably Type-Safe Code