Application Domain Hosts
Each .NET Framework application runs in an application domain under the control of a host that creates the application domain and loads assemblies into it. The host has access to information about the code (evidence), such as the zone in which the code originates, or the digital signatures of the assemblies in the application domain. A trusted host is a host that has permission to provide the common language runtime with this kind of information. The System.AppDomain class provides the application domain functionality used by hosts.
The following table shows the types of application hosts.
Application domain host |
Description |
|---|---|
Browser host (for example, Microsoft Internet Explorer) |
Runs code within the context of a Web site. |
Custom-designed hosts |
Creates domains and loads assemblies into domains, including dynamic assemblies. Can be written in managed or unmanaged code. |
Server host (for example, ASP.NET) |
Runs code that handles requests submitted to a server. |
Shell host |
Launches applications (.exe files) from the shell. |
After creating a new application domain, a host can specify the policy to apply to code within the application domain. This policy is always subject to the enterprise, machine and user policy. A host can reduce the set of permissions that machine and user policy allow but cannot expand it. Policy can be set only once for an application domain. To set application domain policy, the host must be granted the security permission (provided through the SecurityPermission class) for controlling domain policy.
After application domain policy is set, all subsequently loaded assemblies are granted permissions under the new policy (enterprise, machine, user, and application domain policy). Previously loaded assemblies get permission grants under the pre-existing policy (enterprise, machine and user policy only). The permissions granted to these assemblies are not reevaluated under the new application domain policy.
A trusted host can provide information (evidence) to the runtime about assemblies that are loaded into the application domain. If a domain host does not have the appropriate SecurityPermission for controlling evidence, the runtime uses the security enforced on the host to determine the security to enforce on the assembly.
In some situations, evidence that would normally be provided by a trusted application domain host is actually provided by the loader. Typically, after an application domain is created, the application domain host loads the first (main) assembly into the application domain and calls into that assembly to begin execution. When code in the first assembly references code in another assembly, the loader resolves the reference, loads the appropriate assembly into the application domain, and supplies the evidence about the assembly to the runtime. In this situation, the trusted application domain host that provided the evidence for the original assembly does not provide evidence to subsequently loaded assemblies.