Application Domains-Learning

Original: https://www.cnblogs.com/1996V/p/9037603.html

application domain

A traditional unmanaged program is hosted directly in a Windows process, and the managed program is hosted on the. NET virtual machine on the CLR, and in this part of the resource that is controlled in the CLR, is partitioned into logical partitions, which are called application domains and are a concept defined in the. NET framework.
Because heap memory construction and deletion are managed by GC, it reduces the chance of human error, based on this feature. NET emphasizes that the security and robustness of managed code programs can be enhanced by the strong management of the CLR in a process that creates isolated areas of resource logic that are not affected by each region's applications.

Familiarity with assembly loading rules and AppDomain is a prerequisite for plug-in programming under. NET technology. The AppDomain concept is not complicated.
When starting a managed program, the CLR is the first to start, in which the code initializes three logical regions, first the Systemdomain system program domain, then the shareddoamin shared domain, and finally the {assembly name}domain Default domain.

The System program domain maintains a number of system construction items that we can use to monitor and manage other application domains. Shared domains hold some information that other domains will access, and when the shared domain is initialized, the mscorlib.dll assembly is automatically loaded into the shared domain. The default domain uses the information that stores its own assembly, and our main assembly is loaded into the default domain, executing the program entry method, and all the expense that occurs in the absence of a special action takes place in that domain.

We can create and unload the application domain in code, the domain is isolated from the domain, the a domain is not affected by the B domain, and the domain is specified for each loaded assembly, and the domain is not specified in the code, and is loaded into the default domain by default.
The AppDomain can be imagined as a group concept, and the AppDomain contains a set of assemblies that we load. We unload the AppDomain through code, that is, all of the assemblies loaded in the AppDomain are unloaded in the relevant area of memory.

The purpose of the AppDomain is edge isolation, which allows the program to run for a long time without restarting, and the system built around that concept allows us to use it. NET technology for plug-in programming.

When we want the program to add a new feature or change a piece of functionality without shutting it down, we can do this by loading the main module of the program into the default domain by default, creating a new application domain, and then loading the assembly of the module that needs to be changed or replaced into that domain. Uninstall the domain directly whenever you change or replace it. And because of the isolation of the domain, I load the same assembly in Domain A and B, and the domain A and B will each have assembly data with different memory addresses but identical data.

Cross-border access

In fact, in development we should also pay attention to the operation of cross-domain access objects (that is, the assembly code in domain A directly calls the objects in the B domain) is different from normal programming, the application in one domain does not directly access code and data in another domain, for such in-process cross-domain access operations are divided into two classes.

One is to marshal by reference, need to inherit System.MarshalByRefObject, pass the object's proxy reference, and the source domain has the same life cycle.
The second is marshaling by value, which needs to be marked by [Serializable], which is a copy passed by serialization, regardless of the object of the source domain.
Either way involves marshaling and unpacking two domains directly, so cross-domain access calls do not apply to excessive frequency.
(for example, you are calling objects like this: Var user=new user (); now you do: Var user= (user) {application domain object instance}. CreateInstanceFromAndUnwrap ("Model.dll", "Model.user"); )

It is important to note that the application domain is the division of the Assembly, and the threads in the process are two horizontal and vertical, with a different orientation, and the 2 concepts should not be compared together. We can view the domain where the execution thread is located through Thread.getdomain.
The application domain is the System.AppDomain class in the class library, and some of the important members are:

        Gets the current application domain of the current System.Threading.Thread public static AppDomain CurrentDomain {get;}        Creates a new application domain with the specified name public static AppDomain CreateDomain (string friendlyname);        Uninstalls the specified application domain.        public static void Unload (AppDomain domain);        Indicates whether CPU and memory monitoring of the application domain is enabled for the current process, which can be monitored based on the relevant properties after opening. public static bool monitoringisenabled {get; set;} The first event that occurs when the current domain managed code throws an exception, the public event eventhandler<firstchanceexceptioneventargs> can be used in the framework design Firstchanceexceptio        N        The event is called when an exception is not captured, such as the code catches only a exception, actually produces a B exception, then the B exception is not captured.        public event Unhandledexceptioneventhandler UnhandledException; Assigns the specified value to the specified application domain property.        The locally stored value of the application domain, which is not divided into contexts and threads, and can be obtained through GetData.        public void SetData (string name, object data); If you want to use managed code to override the CLR's default behavior Https://msdn.microsoft.com/zh-cn/library/system.appdomainmanager (v=vs.85). aspx public        AppDomainManager Domainmanager {get;} Returns the configuration information for the domain, such as the node information that is configured in config public appdomainsetup setupinformation {get;} 

Application domain: Https://docs.microsoft.com/zh-cn/dotnet/framework/app-domains/application-domains

AppDomain and AppPool

Note: The AppDomain application domain here and the AppPool application pool in IIS are 2 concepts, and AppPool is the unique concept of IIS, which also corresponds to the concept of a group, groups the Web site, and then makes some of the groups such as process model, CPU, memory, Advanced configuration of the request queue.

Application Domains-Learning