Concepts of appdomain, assembly, process, and thread

Appdomain is the unit of operation of CLR. It can load assembly, create objects, and execute programs.
Appdomain is the basic mechanism for CLR to implement code isolation. Each appdomain can be run and stopped independently, and each appdomain has its own default exception handling;
The operation failure of one appdomain does not affect other AppDomains. After being loaded by the CLR host (Windows Shell or internetexplorer or SQL Server), the CLR creates a default appdomain, the entry point of the Program (main method) it is executed in the default appdomain. 1. appdomain vs Process
Appdomain is created in a process. A process can have multiple AppDomains. An appdomain can belong to only one process. 2. appdomain vs thread
In fact, there is no good comparison between the two. Appdomain is a static concept, which only limits the boundaries of objects. A thread is a dynamic concept, which can run in different
Appdomain.
Multiple Threads can be created in an appdomain, but the code can only be executed in this appdomain. The system. Threading. thread object in CLR is actually a soft thread, which cannot be recognized by the operating system; the operating system can recognize hard threads.
A soft thread only belongs to one appdomain, and a hard thread is used to traverse the appdomain. When a hard thread accesses an appdomain, a soft thread is generated for an appdomain. Hard thread has Thread Local Storage (TLS), which is used by CLR to store the appdomain reference and softthread reference of the hard thread. When a hard thread traverses another appdomain, these references in TLS also change.
Of course, this statement may be related to the implementation of CLR. 3. appdomain vs assembly
Assembly is the basic deployment unit of the. NET program. It can provide the CLR with metadata for identifying types and so on. The Assembly cannot be executed independently. It must be loaded into the appdomain, and then the appdomain creates the objects in the Assembly.
One assembly can be loaded by multiple AppDomains, and one appdomain can be loaded by multiple assemblies. When each appdomain references a type, the corresponding Assembly needs to be initialized in the respective appdomain. Therefore, each appdomain maintains a static variable of the class. 4. appdomain vs object
Any object can belong to only one appdomain. Appdomain is used to isolate objects. Objects in different AppDomains must communicate through proxy (reference type) or clone (value type. The reference type must inherit system. externalbyrefobject to be marshal/unmarshal (proxy ).
The value type must be set to the serializable attribute to be cloned by Marshal/unmarshal ).
5. appdomain vs assembly code
What is the relationship between the source code of the appdomain and the assembly? The Code of each Assembly is loaded to each appdomain separately?
First, we need to divide the Assembly into three categories.
1. mscorlib, which is the assembly to be referenced by every. Net program.
2. GAC. This is a strongly-named public assembly that can be referenced by all. net programs.
3. Assembly not in GAC. This is a common assembly. It can be a good name and is not placed in GAC. Start CLR. When entering entry point, you can set the loaderoptimization attribute: [loaderoptimization (loaderoptimization. multidomain]
Static void main ()
You can set three different enumeration values for the {...} loaderoptimization attribute to set the code storage and access methods for the preceding three sets. Loaderoptimization enumeration/attribute

Value	Expected domains in process	Each domain expected to run...	Code for mscorlib	Code for assemblies in GAC	Code for assemblies not in GAC
Singledomain	One	N/	Per-Process	Per-Domain	Per-Domain
Multidomain	Bytes	Same program	Per-Process	Per-Process	Per-Process
Multidomainhost	Bytes	Different programs	Per-Process	Per-Process	Per-Domain

1. singledomain: because only one appdomain is started, the code is directly loaded into the appdomain to access static variables more quickly. 2. multidomain, all assembly code is process-level, so all AppDomains only access one copy of code. This greatly reduces the memory occupied by the program. However, because the static variables of the Assembly are still in each appdomain, you must obtain the reference of appdomain before converting the code to access static variables, the speed will be affected. 3. multidomainhost, only the GAC code is shared, and non-GAC assembly is still loaded into the used appdomain, which improves the access speed of static variables, of course, it also increases the memory occupied by the program. Either way, mscorlib is always process-level, that is, only one mscorlib code is in the memory. Dynamic DLL loading and unloading in C #

It is easy to load and uninstall DLL in C ++. loadlibrary and freelibrary allow you to easily load the DLL in the program and then uninstall it anywhere. In C #, we can also use assembly. LoadFile to dynamically load the DLL, but when you try to uninstall it, you will be surprised to find that assembly does not provide any uninstall methods. This is because the automatic garbage collection mechanism of the managed code will do this, So C # does not provide a function to release resources, and all is done by garbage collection.

This raises a problem. The DLL loaded with assembly may only be released at the end of the program. This also means that the loaded DLL cannot be updated during the program running. This function is very necessary in some programming. Consider that you are using the reflection mechanism to write a program to view the details of all functions in the DLL, the program provides a menu for users to select the DLL file. In this case, the program must be able to uninstall the DLL. Otherwise, the program must be restarted once the user obtains the new dll version, re-select to load the DLL file, this design is intolerable to the user.

C # also provides a way to dynamically uninstall DLL through appdomain. Appdomain is an environment for Independent Application Execution. When the appdomain is uninstalled, all resources in the environment will be recycled. For more information about appdomain, see msdn. The following code uses appdomain to dynamically uninstall dll,

Using system;
Using system. Collections. Generic;
Using system. text;
Using system. Threading;
Using system. reflection;
Namespace unloaddll
{
Class Program
{
Static void main (string [] ARGs)
{
String callingdomainname = appdomain. currentdomain. friendlyname; // thread. getdomain (). friendlyname;
Console. writeline (callingdomainname );
Appdomain ad = appdomain. createdomain ("DLL unload test ");
Proxyobject OBJ = (proxyobject) ad. createinstancefromandunwrap (@ "unloaddll.exe", "unloaddll. proxyobject ");
OBJ. loadassembly ();
OBJ. Invoke ("testdll. class1", "test", "it's a test ");
Appdomain. Unload (AD );
OBJ = NULL;
Console. Readline ();
}
}
Class proxyobject: marshalbyrefobject
{
Assembly = NULL;
Public void loadassembly ()
{
Assembly = assembly. LoadFile (@ "testdll. dll ");
}
Public bool invoke (string fullclassname, string methodname, Params object [] ARGs)
{
If (Assembly = NULL)
Return false;
Type TP = assembly. GetType (fullclassname );
If (TP = NULL)
Return false;
Methodinfo method = TP. getmethod (methodname );
If (Method = NULL)
Return false;
Object OBJ = activator. createinstance (TP );
Method. Invoke (OBJ, argS );
Return true;
}
}
}

Note:

1. To allow an object to pass through the appdomain boundary, it must inherit the marshalbyrefobject class; otherwise, it cannot be used by other AppDomains.

2. Each thread has a default appdomain, which can be obtained through thread. getdomain ().