As we all know, processes are the basic units of the operating system for resource scheduling and allocation, and each process actually represents the entire process from boot to end of the current application. For each. exe file in Windows, it is hosted by a process at run time. Unlike an unmanaged. exe file, a managed. exe file does not load the assembly directly into the current process, but instead loads the assembly into the application domain and then loads the application domain into the process. Each process can host multiple application domains. Therefore, for managed programs, each process can host multiple applications, which also increases the performance of the application, because process switching takes more performance than application domain switching.
1.1 Features of application domains
Why should a managed program use an application domain? The advantages are summarized as follows:
1. Errors that occur in one application do not affect other applications.
2. Because type-safe code does not cause memory errors, using application domains ensures that code running in one domain does not affect other applications in the process.
3. Ability to stop a single application without stopping the entire process.
4. When you use an application domain, you can uninstall code that runs in a single application.
5. Code that runs in one application cannot directly access code or resources in other applications.
To enforce this isolation, the common language runtime prohibits direct calls between objects in different application domains. To pass objects between domains, you can access these objects either by copying them or by proxy. If the object is copied, the call to the object is called locally. In other words, the caller and the referenced object are in the same application domain. If the object is accessed through a proxy, the call to the object is a remote call. In this case, the caller and the referenced object are in a different application domain. The remote call infrastructure that is invoked between domains is the same as the underlying structure of the call between two processes or between two machines. Therefore, the metadata for the referenced object must be available to two application domains so that the method call is compiled correctly with JIT. If the calling domain does not have access to the metadata of the invoked object, the compilation may fail and throw an exception of type System.IO.FileNotFound.
1. The scope of the code behavior is determined by the application in which it runs.
In other words, the application domain provides configuration settings such as application version policy, the location of any remote assembly it accesses, and location information for assemblies that are loaded into the domain.
2. The permissions granted to code can be controlled by the application domain in which the code runs.
1.2 Creating an application domain
. NET provides the relevant classes and methods to obtain basic information about the current application domain, as well as to create and configure the members of an application domain. Where the AppDomain class is the programming interface of an application domain, this class includes methods that create and unload domains, create instances of each type in the domain, and register various notifications, such as application domain uninstall. For uninstall of application domains, it will be covered in section 3rd. 1.3.
Code Listing 1-1 shows how to create an application domain.
Code listing 1-1 Creating an application domain
Class Program
{
static void Main (string[] args)
{
AppDomain mydomain= appdomain.createdomain ("Xuanhundomain");//Create an application domain named Xuanhundomain
Console.WriteLine ("MyDomain name is: {0}", mydomain.friendlyname);//output created program domain name
Console.WriteLine ("The current program domain name is: {0}", AppDomain.CurrentDomain.FriendlyName);//output current program domain name
Console.readkey ();
}
}
The output results are shown in Figure 1-1.
Figure 1-1 Output application domain name