In-depth understanding of the application domain concept in. Net framwork

Abstract: Appdomain is a concept exclusive to the. NET Framework. Microsoft's own reference concept cannot be found in other technical systems. Many people think that the concept can be the same as that of a process. I do not agree with it: first, "process" is a concept in an operating system. It has its own definition and functions in a system such as a virtual machine or framework, obviously, appdomain is incorrect. Now is the virtual machine era, Java is called JVM (Java Virtual Machine),. NET is called framework (framework ). There are many similarities and differences between the two systems, but what I'm interested in is that. NET is called "appdomain" (Application Program Domain. How can this concept be accurately understood for. NET development? What do you need to pay attention to when using it?

The appdomain explanation in Microsoft's. Net document is quite simple (but not very clear J): "An independent environment in which an application runs ". Managed for executionCodeProvides isolation, uninstallation, and security boundaries. How can we understand it? I want to know this concept accurately:

1. appdomain is a concept exclusive to the. NET Framework. Microsoft's own reference concept cannot be found in other technical systems. Many people think that the concept can be the same as that of a process. I do not agree with it: first, "process" is a concept in an operating system. It has its own definition and functions in a system such as a virtual machine or framework, obviously, appdomain is incorrect. Second, "There is no one-to-one association between application domains and threads. Multiple Threads can belong to one application domain, although the given thread is not limited to an application domain, the thread is executed in an application domain at any given time." (Description in. NET Framework SDK). Does it make sense to replace "application domain" with "process?

2. Isolation. It is not surprising that some people directly implement the process. appdomain has the feature of code execution isolation, just as the process does. Appdomain objects and codes can be considered isolated from each other. Even the code in an appdomain calls the object (data or method) of another appdomain ), the appdomain class must be similar to the "column set/scattered set" in DCOM (in the class inheritance relationship, the appdomain class inherits from the marshalbyrefobject class ). Each appdomain can be debugged, started, and stopped independently, and has its own default exception handling function. An appdomain crashes without affecting other AppDomains. It can be understood as a "logical process" of. net ".

. Net allows different versions of the same application to coexist, eliminating the so-called "DLL hell ". By creating different AppDomains, we can run the 1.0 and 2.0 versions of a hosted assembly at the same time (as long as they do not have incompatible access to a specific resource)

3. Security. Code isolation prevents the impact of a dangerous code on other AppDomains. In addition, you can assign a specific security allocation to determine that the Execution Code in the appdomain protects access to system security resources.

4. Independence. Each appdomain is allocated a dedicated storage area (application domain local storage) by the. NET Framework ). Any object can access the local storage area of its current appdomain, which is shared by objects in the entire appdomain, it also includes the thread that enters the appdomain (the thread running on the same appdomain can communicate through this local storage ).

5. Relationships with processes, threads, and assembly. The same process belongs to the many-to-one relationship, that is, a process can have multiple AppDomains, but the appdomain can only exist in a process (obviously, as in the same text: processes are different from appdomain ). By default, if you do not create multiple AppDomains by yourself, an appdomain is automatically created after a process starts. Thread execution can involve multiple AppDomains, but at a specific time, the thread only exists in one appdomain, And the thread can enter other AppDomains. An instance of an Assembly belongs to a specific appdomain, which is loaded within its own range, and corresponding objects are created according to the Assembly. Appdomain is the execution environment of the Assembly. At the same time, the Assembly acts as a static entity and can be loaded and executed by multiple AppDomains.

Many peopleArticleI talked about related programming (but I didn't know what appdomain is), and I don't want to copy it, it basically involves creating and uninstalling appdomain, obtaining the current appdomain instance, operating appdomain, creating object calling objects in appdomain, loading specific assembly, executing program, and coordinating between appdomain (callback, event, etc). Refer to the URLs I collected:

Appdomain reference

Http://tech.ccidnet.com/pub/article/c1136_a30763_p1.html

Http://www.yesky.com/SoftChannel/72342380484755456/20030819/1722679_2.shtml

Http://www.microsoft.com/china/msdn/library/dncscol/html/csharp05162002.asp

Http://wwwb.pconline.com.cn/pcedu/empolder/gj/vb/doc/10712_2.htm

Http://www.csdn.net/Develop/Read_Article.asp? Id = 19285

Http://www.WebDN.com/web_file/program/asp.net/06020806153.asp

SDK reference:

MS-help: // Ms. VSCC/ms. msdnvs.2052/cpref/html/frlrfsystemappdomainclasstopic.htm

MS-help: // Ms. VSCC/ms. msdnvs.2052/cpref/html/frlrfsystemappdomainmemberstopic.htm

We have learned from the previous discussion that in general, we do not need to care about appdomain. However, this concept appears in. net is not redundant and has its own reasons. What are the specific scenarios for using appdomain?

1. The assembly to be isolated. For example, some code that is particularly prone to crash can be considered to run separately in a specific appdomain.

2. If you need to divide Security Execution boundaries for your code for different security-level assemblies, consider creating different security-level codes separately in an appdomain with different security information set.

3. In terms of performance, some assembly may consume a large amount of resources, although there is basically no resource consumption vulnerability in the managed environment, however, there will always be a situation where intensive access at a specific time will consume a large amount of resources. In this case, you can consider creating a separate appdomain. When the resource consumption exceeds the critical point, uninstall the appdomain to meet system operation requirements. In Asp.net, different AppDomains are used to provide support to prevent the crash of one application from affecting other Asp.net applications. At the same time, if the system that does not restart IIS and does not affect the service provision of Asp.net itself, an appdomain is detached and a new appdomain is started, ideally, the web system can be online for a long time (this was an expensive UNIX feature and was finally referred to by MS ).

4. Run the same application assembly of different versions simultaneously. This is a big problem in the com era. Now, through appdomain, we have implemented the implementation of two different assembly versions in one process, which can achieve good compatibility.

5. dynamically load some programs.
From: http://blog.csdn.net/LV_Q/archive/2008/01/16/2047107.aspx