Another internal thread I thought i'd share...

Q: I want to sandbox objects of certain types that will be running in my process so that if anything in these objects crashes for any reason, code in the other objects continue to execute.  I’m assuming AppDomains will be my solution here.  First, is that a good assumption?

Second, if these objects are calling into unmanaged code that is creating threads that could potentially throw exceptions, will AppDomains help me here?

A: (again from a senior guy on our team)

If code has UnmanagedCodePermission, SkipVerificationPermission, FullTrust, or a number of other highly privileged permissions, it has the ability to toast the entire process.

If code only has Execute or similar low-trust permissions, it cannot toast the entire process.  However, there it can still cause a denial of service by spawning many threads that consume the CPU, or allocating lots of memory to swamp the GC, or blocking inside a Finalize method so the finalizer queue grows without limits.

AppDomains allow you to separate the managed state of different applications so that they cannot write over each other without performing unsafe highly privileged operations.  AppDomains allow you to shut down and unload individual applications without disturbing the other applications in the process.  Currently AppDomains are a weak boundary with respect to security.  Over time, we’ll be looking at strengthening that security boundary.

Threads travel between AppDomains.  If you call between AppDomains and an exception is thrown, that exception will be marshaled back across the remoting boundary.