AppDOMain (excerpt)

The AppDomain is the CLR's running unit, which can load assembly, create objects, and execute programs.
The AppDomain is the basic mechanism by which the CLR implements code isolation.　　Each appdomain can be run individually, stopped, and each AppDomain has its own default exception handling, and an AppDomain fails to run without affecting the other AppDomain. After the CLR is loaded by the CLR Host (Windows shell or InternetExplorer or SQL Server), to create a default AppDomain, the entry point of the program (Main method)　　is executed in this default AppDomain. 1.AppDomain vs Process
The AppDomain is created in a process and can have more than one AppDomain within a process.　　An AppDomain can belong to only one process. 2.AppDomain vs Threads
In fact, there is no good contrast between the two. An AppDomain is a static concept that restricts the bounds of an object, and a thread is a dynamic concept that can run in a different AppDomain.　　Multiple threads can be created within an AppDomain, but they cannot be qualified to execute code within the AppDomain. The System.Threading.Thread object in the CLR is actually a soft thread, which cannot be recognized by the operating system, and the operating system can recognize hard thread. A soft thread belongs to only one AppDomain, which is hard thread through the AppDomain. When hard thread accesses an AppDomain, an AppDomain generates a soft thread for it. Hard thread has thread local storage (TLS), which is used by the CLR to store the current AppDomain reference for this hard thread and the soft thread reference. When a hard thread crosses into another AppDomain, these references in TLS also change.　　Of course, this statement is probably related to the implementation of the CLR. 3.AppDomain vs Assembly
Assembly is the basic deployment unit for. NET programs, which provides the CLR with metadata for identifying types, and so on. The assembly cannot be executed alone, it must be loaded into the AppDomain, and then the AppDomain creates the objects in the assembly. A assembly can be loaded by multiple AppDomain, and an AppDomain can load multiple assembly. Each AppDomain refers to a type that needs to initialize the corresponding assembly in its own AppDomain.　　Therefore, each AppDomain maintains a static variable of a class separately. 4.AppDomain vs Object
Any object can belong to only one AppDomain. The AppDomain is used to isolate objects, and objects between different AppDomain must communicate through proxy (reference type) or clone (value type). Reference types need to inherit System.MarshalByRefObject to be Marshal/unmarshal (Proxy).
The value type needs to be set serializable property to be Marshal/unmarshal (Clone). 5.AppDomain vs Assembly Code
What is the relationship between the AppDomain and the source code of the assembly? Each assembly's code is loaded into each appdomain separately?
First, we're going to divide the assembly into 3 categories.
1.mscorlib, which is the assembly to which each. NET program is referenced.
2.GAC, this is a strong-named public assembly that can be referenced by all. NET programs.
3.Assembly not in the GAC, this is an ordinary Assembly, which can not be strongly named and not put into the GAC. Starting the CLR, you can set the Loaderoptimization property when entering entry point: [Loaderoptimization (Loaderoptimization.multidomain]
static void Main ()
{...} The Loaderoptimization property can set three different enumeration values to set how code is stored and accessed for the three assemblies previously said. Loaderoptimization Enumeration/attribute Each not in GAC

Value	expected Domains in Process	Domain expected to Run ...	Code for MSCORLIB	Code for assemblies in GAC	Code for assemblies
Singledomain	One	N/A	Per-process	Per-domain	Per-domain
MultiDomain	Many	Same program	Per-process	Per-process	Per-process
MultiDomainHost	Many	Different Programs	Per-process	Per-process	Per-domain

1.SingleDomain, because only one AppDomain is started, code is loaded directly into the AppDomain, which is quicker to access static variables. 2.MultiDomain, all assembly codes are process-level, so all AppDomain accesses only one copy of the code. This greatly reduces the memory consumed by the program, but because the static variables of the assembly are still in each AppDomain, the code access static variables need to be referenced by the AppDomain before being converted, and the speed will be affected.  3.MultiDomainHost, only the GAC code is shared, non-GAC assembly will still be loaded into the AppDomain being used, which increases the speed of static variable access and, of course, increases the memory consumed by the program. Either way, mscorlib is always at the process level, that is, only one copy of the mscorlib code is in memory. dynamically loading and unloading DLLs in C #

Loading and unloading DLLs in C + + is an easy task, and LoadLibrary and FreeLibrary allow you to easily load DLLs in your program and unload them anywhere. In C # We can also use Assembly.loadfile to implement dynamic load DLLs, but when you try to uninstall, you will be surprised to find that assembly does not provide any way to uninstall. This is because the automatic garbage collection mechanism of managed code does this, so C # does not provide a function to free up resources, all from garbage collection.

This raises the question that DLLs loaded with assembly may be released only at the end of the program, which also means that the loaded DLL cannot be updated while the program is running. And this function is necessary in some programming, considering you are using reflection mechanism to write a view of all the functions of the DLL program, the program provides a menu allows the user to select the DLL file, you need to let the program can unload the DLL, or once the user re-get the new version of the DLL, You must restart the program and re-select the load DLL file so that the design is intolerable to the user.

C # also provides a way to implement a dynamic unload DLL, implemented through an AppDomain. An AppDomain is an environment in which an application is executed independently, and all resources in that environment will be reclaimed when the AppDomain is unloaded. For more information about the AppDomain, refer to MSDN. Here's the code for dynamically unloading DLLs using the AppDomain.

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 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;} 
} 
} 

AppDOMain (excerpt)