Creating and Configuring Application Domains
After a host has determined where domain boundaries lie, based on the criteria described in the previous section, the host uses the CreateDomain method of the System.AppDomain type to create domains in which to run user code. Each application domain contains a collection of name/value pairs in which a host can store information about a domain. The name/value pairs are passed as a parameter to CreateDomain.
The .NET Framework defines a number of properties that are natively understood by the runtime. The names of these properties are defined by the static strings in the class System.AppDomain. A host can set the natively understood properties to customize the application domain. For example, these properties can control the way in which code running in different domains is isolated. The name/value pairs can be extended so that hosts can define custom properties in which they can store information specific to their scenario.
In general, the isolation provided by application domains takes two forms:
Application domains prevent code running in one application domain from affecting other domains by preventing types in one domain from seeing and calling types in other domains. Application domains rely on the fact that code has been verified to protect against memory faults.
The host controls where the runtime finds code to load into a particular application domain on its behalf. This is important because it prevents code from one application from inadvertently affecting other applications. The ability to scope requests to load code in this way differs significantly from the way in which Microsoft Win32 and COM currently work. Currently, in Windows, the resolution scope is the entire computer because any application can use any code described in the registry or placed in a well-known location such as the Windows system directory. Sharing in this manner is currently the default, and this behavior contributes to DLL conflicts.
In addition to establishing a scope for the way in which code is to be loaded, it is also important to scope configuration information to an application. However, this is not presently possible for many configuration settings.
For example, if you configure a remote computer on which to run a COM class, the setting of the RemoteServerName key in the registry for a particular class affects all applications that use that class. Similar to unintended sharing of code, the unintended sharing of configuration data prevents an application from completely controlling its own behavior.
The System.AppDomainFlags.ApplicationBase and System.AppDomainFlags.ConfigurationFile properties, respectively, control the ability to specify the directories in which the runtime looks for assemblies and scopes the configuration settings for a particular application domain by.
ApplicationBase establishes a root directory for the application domain, under which the runtime looks for private assemblies. If a host permits assemblies to be loaded from disk, it must provide an ApplicationBase so that the runtime knows where to look for the loaded assemblies.
The ConfigurationFile property specifies the name of an XML file that contains settings used to configure the application running in the application domain. Examples of settings in the application configuration file include assembly versioning rules and instructions for locating types that can be accessed remotely by the types running in the application domain.
For descriptions of other properties available for configuring an application domain, see the documentation for the AppDomain class.
Security Note The default value for the AppDomainSetup.DisallowCodeDownload property is false. This setting is unsafe for services. To help prevent services from downloading partially trusted code, set this property to true.