The AppDomain resembles a lightweight process, which is a logical container when the. Net/mono code runs.
In general, the code we develop runs in the AppDomain (the default AppDomain) we created at run time, unaware of the presence of the AppDomain, and less need to focus on the AppDomain. In other cases, however, it may be necessary to create additional AppDomain in the application, for example:
- dynamically Uninstalling Assemblies : We know that in. Net/mono, assemblies can be loaded dynamically at run time, but the specific assemblies that have been loaded into memory cannot be unloaded, which means that the loaded assembly cannot be updated while the program is running. And this function is very necessary in some programming, the most common is the plug-in architecture. In addition, because the loaded assembly is released at the end of the application, this also creates an unnecessary memory footprint. Now, this can be done through the AppDomain.
- Implementing assembly Isolation : Some code that is prone to crashes can be considered to run separately in an AppDomain. For example, the use of different AppDomain to prevent one application from crashing affects other ASP. NET applications, but also can be unloaded without restarting the system, without restarting IIS, without affecting the ASP. Then launch the new AppDomain, ideally able to implement the Web system for a long time on-line (which was formerly an expensive UNIX feature that is now finally being "borrowed" by Microsoft).
- Restrict code security permissions : In some cases, to prevent potentially harmful effects that some untrusted code may have on other AppDomain, you can apply different levels of security to ensure the security of critical resources.
- load different versions of the same assembly : This is a big problem in the COM age, and now through the AppDomain, you can load different versions of the two assemblies simultaneously in one process and be able to achieve good compatibility.
- Efficient use of resources : Some assemblies can be resource-intensive from a performance point of view, although there is virtually no resource consumption vulnerability in a managed environment, but there is always a case of dense access at specific times and significant resource consumption, consider creating a separate AppDomain, Uninstall the AppDomain after the resource consumption exceeds the critical point to accommodate system operation requirements.
- reduce memory footprint : Allow different AppDomain to share assemblies in. NET, provided that these assemblies must be strong-named and in the GAC. For example, in ASP., the assembly sharing policy uses MultiDomainHost by default, which means that all assemblies in the GAC will be shared by all AppDomain (that is, all ASP. NET applications) as shared (domain neutral) assemblies. We can imagine how much memory savings this can bring.
The role of the AppDomain
