Application Domains and Assemblies
This topic describes the relationship between application domains and assemblies. You must load an assembly into an application domain before you can run the application. Running a typical application causes several assemblies to be loaded into an application domain. By default, the common language runtime loads an assembly into the application domain containing the code that references it. In this way, the assembly's code and data are isolated to the application using it.
If an assembly is used by multiple domains in a process, the assembly's code (but not its data) can be shared by all domains referencing the assembly. This reduces the amount of memory used at run time. This method of sharing an assembly's code is similar to the way in which the Microsoft Win32 API LoadLibrary shares code pages among processes that reference the same DLL. 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. For more information, see the documentation for CorBindToRuntimeEx in the common language runtime Hosting Interfaces Specification found in the .NET Framework SDK.
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.
When you decide whether to load assemblies as domain-neutral, you must make a tradeoff between reducing memory use and performance. 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.