[C # advanced series] 22 CLR host and AppDomain,

[C # advanced series] 22 CLR host and AppDomain,

About boarding and AppDomain

When Microsoft develops CLR, it is implemented as a COM server contained in a DLL.

Any Windows application can host (accommodate) CLR. (In short, the CLR can include CLR by referencing the DLL in a DLL)

When the clr com server is initialized, a default AppDomain is created. This AppDomain is destroyed only when the process ends.

However, the host program can also require the CLR to create an additional AppDomain.

Because process creation is costly and requires a large amount of memory to virtualize the address space of the process.

So people just want to run multiple programs in a process.

Therefore, the CLR is embedded in the process, and the AppDomain concept is exclusive. The AppDomain is designed to provide isolation.

Of course, this is not the reason. The host provides custom and scalable capabilities for the application. However, this will cause some malicious dll to destroy the data structure and code of the application, you can also use security context to access resources that are not authorized to access.

CLR AppDomain can solve this problem, allowing third-party Untrusted code to run in existing processes, while CLR ensures that the data structure, code and security context are not abused or destroyed.

AppDomain: The application domain.

The following are specific AppDomain functions:

• The Code of one AppDomain cannot access the object created by the code of another AppDomain. In this way, the two AppDomains are isolated. This isolation makes AppDomain easily unmount in the process and does not affect the running code of other AppDomains.
• AppDomain can be detached. (As mentioned above, the default first AppDomain cannot be uninstalled)
• AppDomian can be separately protected. (Each AppDomain has its own permission set)
• AppDomain can be configured separately. (Each AppDomain has its own configuration settings, mainly affecting the CLR Loading Method in AppDomain. Involves search path, version binding redirection, shadow copying, and loader optimization)

A process runs a clr com server and the CLR manages multiple AppDomains. Each AppDomain can have its own programs. Some assembly can be shared in AppDomain, such as MSCorLib. dll and. NET is an inseparable type. It is automatically loaded during CLR initialization. It has its own loader heap to maintain type objects and is shared by all AppDomains as a "AppDomain" neutral method.

Access objects across AppDomain boundaries

The AppDomain is designed for isolation, and the code of one AppDomain cannot access the code of another AppDomain.

However, there is no way to achieve this, in order to implement communication between two AppDomains.

AppDomain-based communication can be divided into three types: by reference mail type, by value mail type, completely cannot mail type.

A process can have multiple threads and multiple AppDomains, but they do not have a one-to-one relationship.

Although a thread can only execute the code in one AppDomain at a time, a thread can execute the code in one AppDomain and then execute the code in another AppDomain. It can also view the AppDomain in which it is located.

However, as the relationship is not used and a little complicated, we only understand the central idea:

Push by reference: in fact, AppDomain is passed to another AppDomain, for example, A references object B. When the function of B is executed, the thread actually switches back to B, after the call, switch back to.

Value-based delivery: This is actually to serialize the objects in one AppDomain and put them in another AppDomain for deserialization.

Uninstall AppDomain

Call the static method AppDomain. Unload.

Uninstalling AppDomain will unload all the assembly and release the loader heap.

Main steps:

At any time, there will be only one thread to call the Unload method, and no multiple threads will call the method at the same time.

How the host uses AppDomain

Console UI applications, NT Service applications, Windows Forms applications, and WPF applications are self-hosted (that is, self-hosted CLR) applications.

They all have hosted exe files. After the initialization process of the exe files is hosted, the "gasket" (MSCorEE. dll). The gasket checks the CLR header information of the application assembly and determines the version of CLR to be loaded into the process. After the CLR is loaded, it checks the Main function after the CLR header is retained, then the program is started after this method is called.

Take ASP as an example. NET. NET requires CLR to create a new AppDomain. Each Web application is identified based on the virtual root directory, and then the CLR is allowed to load the Assembly containing the types exposed by the application to the new AppDomain, create an instance and call the method. If it is not the first request, a new AppDomain will not be created. However, if the client requests different Web applications, a new AppDomain will also be created. It seems to be about those different websites in IIS.

 

Summary:

In this step, I plan to explain my understanding of this thing.

In the. NET world, CLR (clr com server) is loaded on a process, and different AppDomains are loaded on the CLR.

For the programs that we usually write that are created simply using. net, such as the console program, the CLR is actually loaded on a managed exe, and the default AppDomain is loaded at this time. This exe can be used as a host to load more AppDomains. However, you need to manually load this file.

For those that are not. NET unmanaged applications can also load CLR, and a default AppDomain will be loaded at this time. In fact, it can also load more AppDomains as a host.

There may be deviations, But I still hope to correct them!

PS:

The content of this chapter only needs to be written. Further research is needed when the specific AppDomain method is used. (In other words, there is always a feeling that you won't be able to play this thing all your life)