All the managed code is subject to code access security. It is granted a set of code access permissions that determines what resource types it can access and what types of privileged operations it can perform. The Microsoft .NET Framework security system uses evidence to authenticate code to grant permissions. Evidence is used by the .NET Framework security system to identify assemblies. Code access security policy uses evidence to help grant the right permissions to the right assembly. Evidences can be classified of 2 types. Location related evidences and Author related evidences. The location related evidences can have a URL the assembly is obtained from or a directory the assembly is obtained from.

Code access security policy is configured by administrators and it determines the permissions granted to the assemblies. There are four types of policies identified for code access security.

·         Enterprise - Used to apply Enterprise wide policy.

·         Machine - Used to apply machine level policy.

·         User - Used to apply Per-user policy.

·         Application domain-level policy - ASP.NET code access security process is an example of Application domain level policy.

Execution of an Assembly by loading it into Application Domains

An assembly is said to be domain-neutral when its code can be shared by all domains in the process. The runtime host decides whether to load assemblies as domain-neutral when it loads the runtime into a process.

There are three options for loading domain-neutral assemblies:

Load no assemblies as domain-neutral, except Mscorlib, which is always loaded domain-neutral. This setting is called single domain because it is commonly used when the host is running only a single application in the process.

Load all assemblies as domain-neutral. Use this setting when there are multiple application domains in the process, all of which run the same code.

Load strong-named assemblies as domain-neutral. Use this setting when running more than one application in the same process.

In case of loading assemblies as domain-neutral, memory use and performance are at stake. The performance of a domain-neutral assembly is slower if that assembly contains static data or static methods that are accessed frequently. Access to static data or methods is slower because of the need to isolate applications. Each application domain that accesses the assembly must have a separate copy of the static data or method to prevent references to objects in static variables from crossing domain boundaries. As a result, the runtime contains additional logic to direct a caller to the appropriate copy of the static data or method. This extra logic slows down the call.

An assembly is not shared between domains when it is granted a different set of permissions in each domain. This can occur if the runtime host sets an application domain-level security policy. Assemblies should not be loaded as domain-neutral if the set of permissions granted to the assembly is to be different in each domain.