Good example of use of AppDomain

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

• they are an isolation level within an application (making them different from applications)
• they can have threads (making them different from threads)
• exceptions in one appdomain do not affect another
• appdomains cannot access each other's memory
• each appdomain can have different security

I still don't get what makes them necessary. I'm looking for a reasonable concrete circumstance when you would use one.

Answers:

• Untrusted code
• Core application protected
  Untrusted/3rd party plugins are barred from corrupting shared memory and non-authorized access to registry or hard drive by isolation in separate appdomain with security restrictions, protecting the application or server. e.g. ASP.NET and SQL Server hosting component code
• Trusted code
• Stability
  Application segmented into safe, independent features/functionality
• Architectural flexibility
  Freedom to run multiple applications within a single CLR instance or each program in its own.

Anything else?

Probably the most common one is to load assemblies that contain plug-in code from untrusted parties. The code runs in its own AppDomain, isolating the application.

Also, it's not possible to unload a particular assembly, but you can unload AppDomains.

For the full rundown, Chris Brumme had a massive blog entry on this:

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

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

Another benefit of AppDomains (as you mentioned in your question) is code that you load into it can run with different security permissions. For example, I wrote an app that dynamically loaded DLLs. I was an instructor and these were student DLLs I was loading. I didn't want some disgruntled student to wipe out my hard drive or corrupt my registry, so I loaded the code from their DLLs into a separate AppDomain that didn't have file IO permissions or registry editing permissions or even permissions to display new windows (it actually only had execute permissions).

I think the main motivation for having AppDomains is that the CLR designers wanted a way of isolating managed code without incurring the performance overhead of multiple Windows processes. Had the CLR been originally implemented on top of UNIX (where creating multiple processes is significantly less expensive), AppDomains may never have been invented.

Also, while managed plug-in architectures in 3rd party apps is definitely a good use of AppDomains, the bigger reason they exist is for well-known hosts like SQL Server 2005 and ASP.NET. For example, an ASP.NET hosting provider can offer a shared hosting solution that supports multiple sites from multiple customers all on the same box running under a single Windows process.

If you create an application that allows 3rd-party plug-ins, you can load those plug-ins in a separate AppDomain so that your main application is safe from unknown code.

ASP.NET also uses separate AppDomains for each web application within a single worker process.

App Domains are great for application stability.

By having your application consist of a central process, which then spawns out "features" in separate appdomains, you can can prevent a global crash should one of them misbehave.

As I understand it AppDomain's are designed to allow the hosting entity (OS, DB, Server etc...) the freedom to run multiple applications within a single CLR instance or each program in its own. So its an issue for the host rather than the application developer.

This compares favourably with Java where you always have 1 JVM per application, often resulting in many instances of the JVM running side by side with duplicated resources.

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

1) Process-like isolation with low resource usage and overhead. For example, this is what ASP.NET does - it hosts each website in a separate application domain. If it used different threads in the single application domain then code of different websites could interfere with each other. If it hosted different websites in different processes - it would use much resources and also interprocess communication is relatively difficult comparing to inprocess communication.

2) Executing untrusted code in a separate application domain with particular security permissions (this is actually related to 1st reason). As people already said, you could load 3rd party plugins or untrusted dlls into separate application domains.

3) Ability to unload assemblies to reduce unnecessary memory usage. Unfortunately, there is no way to unload an assembly from an application domain. So if you load some big assembly to your main application domain, the only way to free the corresponding memory after that assembly is not needed anymore is to close your application. Loading assemblies in a separate application domain and unloading that application domain when those assemblies are not needed anymore is a solution to this problem.