Determining Application Domain Boundaries
After the hosting code makes the transition from unmanaged to managed code, it must create one or more new application domains in which to run user code. An application domain is a construct that hosts use to isolate code running within a process. This isolation is necessary to ensure that code that is not intended to interact cannot interact. For example, code downloaded from two different Web sites to the Internet Explorer host must be kept separate. The Internet Explorer host creates an application domain for each site to ensure this isolation.
Before a host can create an application domain in which to run user code, it must determine where the boundaries of the new application domain should be. Factors influencing this decision include requirements for restricting a particular type's access to other types, configuration, security, and the ability to unload code when it is no longer needed.
Restricting Access to Types
A type running in an application domain can discover the other types running in the domain and call them directly. However, a type can never discover types that are running in other application domains, and therefore cannot call them. The ability to restrict a type's access to other types is a primary consideration for determining where to create domain boundaries.
Configuration Settings
Application domains are the primary units of configuration in the runtime. Each application domain has an optional associated configuration file that describes settings relevant to the code running in the domain.
For example, a configuration file can contain a list of directories in which to find private assemblies, version-binding information for shared assemblies, the location of types that can be accessed remotely, and so on.
Security
Hosts can set both code-access security policy and role-based security policy for a domain. This enables the host to control the set of permissions granted to code in a particular domain and to set both the current thread's principal and the default principal for role-based security.
For example, a host could define application domain-level code-access security policy to ensure that only code downloaded from a particular site can be run in the domain. Alternatively, a host could set up role-based security principals to implement a custom authentication scheme.
Code Unloading
To unload managed code running in a process from memory so that memory can be used for other purposes, the host must unload the application domain in which the code is running. Individual assemblies or types cannot be unloaded. The host has its own rules governing when you can unload user code. For example, your Internet browser might load managed controls into a site-determined domain. The browser then might have rules that enable it to keep the most recently viewed pages in memory so that the Forward and Back buttons respond more quickly. When the browser determines that a page is no longer needed in memory, it deletes the application domain, thereby also deleting the code for the managed controls.