A good example of using AppDomain

Question

I keep asking about AppDomains in interviews, and I know the basics :

• they are the isolation level in the application (which distinguishes them from applications)
• they can have threads (which sets them apart from threads)
• exceptions in one application do not affect others
• applications cannot access each other.
• each appdomain may have different security

I still do not understand what makes them necessary. I am looking for a suitable specific circumstance if you use it.

Answers:

• Incorrect code
  • The main application is protected.
    Non-forced / third-party plugins are prohibited from damaging shared memory and unauthorized access to the registry or hard drive by isolating themselves in a separate appdomain with security restrictions, protecting the application or server. e.g. ASP.NET Hosting Component Code and SQL Server
• Reliable code
  • Stability
    The application is segmented into secure, independent functions / functionality.
  • Architectural flexibility
    The freedom to run multiple applications in one CLR instance or in each program.

Anything else?

Answer 1

Probably the most common is downloading assemblies containing plugin code from unreliable parties. The code runs in its own AppDomain, isolating the application.

It is also not possible to unload a specific assembly, but you can unload application domains.

For full details, Chris Bramm had a great blog post about this:

http://blogs.msdn.com/cbrumme/archive/2003/06/01/51466.aspx

https://devblogs.microsoft.com/cbrumme/appdomains-application-domains/

Answer 2

Another advantage of AppDomains (as you mentioned in your question) is that the code you load into it can work with different security permissions. For example, I wrote an application that dynamically loads a DLL. I was an instructor, and these were the student DLLs I downloaded. I didn’t want some disgruntled student to destroy my hard drive or distort my registry, so I downloaded the code from my DLLs into a separate AppDomain, which did not have file permissions or permissions to edit the registry or even permissions to display new windows (in fact, he had only permission to execute).

Answer 3

I think the main motivation for AppDomains is that CLR developers need a way to isolate managed code without sacrificing the performance of several Windows processes. If the CLR were originally implemented on top of UNIX (where creating multiple processes is much cheaper), AppDomains might never have been invented.

In addition, although the managed plug-in architectures in third-party applications are certainly good uses of AppDomains, the big reason they exist is because of well-known hosts such as SQL Server 2005 and ASP.NET. For example, an ASP.NET hosting provider may offer a shared hosting solution that supports multiple sites from multiple clients, all in the same field running under the same Windows process.

Answer 4

If you are creating an application that allows third-party plug-ins, you can load these plugins into a separate AppDomain so that your main application is safe from unknown code.

ASP.NET also uses separate AppDomains for each web application as part of a single workflow.

Answer 5

Application domains are great for application stability.

Due to the fact that your application consists of a central process, which then generates “functions” in separate areas of the application, you can prevent a global crash if one of them works erroneously.

Answer 6

As I understand it, AppDomain is designed to allow the hosting object (OS, DB, Server, etc.) the freedom to run several applications in one CLR instance or each program independently. Thus, this is a problem for the host and not for the application developer.

This compares favorably with Java, where you always have 1 JVM for each application, which often leads to many JVM instances running side by side with duplicate resources.

Answer 7

I see 2 or 3 main use cases of separate application domains:

1) Technological isolation with low resource use and overhead. For example, this is what ASP.NET does — it hosts each website in a separate application domain. If he used different streams in the same application domain, the code of different websites could interfere with each other. If he hosted different websites in different processes, he would use a lot of resources, and interprocess communication is relatively difficult compared to inprocess processing.

2) Execution of untrusted code in a separate application domain with certain security permissions (this is actually due to the first reason). As people have already said, you can load third-party plugins or unreliable dlls into separate application areas.

3) Ability to unload assemblies to reduce unnecessary memory usage. Unfortunately, there is no way to unload the assembly from the application domain. Therefore, if you load some kind of large assembly into your main application domain, the only way to free the corresponding memory after this assembly is no longer needed is to close the application. Uploading assemblies to a separate application domain and uploading this application domain when these assemblies are no longer needed is a solution to this problem.