"Anyway, I'm curious about what aspects of the CLR Loader and AppDomains that folks are most interested in/confused about."

One aspect of AppDomains that had me baffled was their relation to remoting. When you want to communicate between appdomains all the aspects of remoting play a role, yet all the documentation of remoting seems to focus on 'real' remoting (between processes or machines).

I can't find the references anymore, but some of the documentation falsely suggested that the whole thing with 'Leases' would not apply to inter-appdomain communication. Well, it does. If I have a propertygrid in a window that somehow accesses an object in a different appdomain, and I don't touch the window for 5 minutes (300 seconds), I get all kinds of errors in the communication because the lease has expired. Yet I know that the 'remote' object is still alive, it is just the lease that timed out.

This kind of issues and surprises pops up when trying to use AppDomains not as containers for separate 'applications', but as integral part of an application. The main reason for doing so is when you need to load 'plugin' assemblies that need the ability to be unloaded. All documentation I can find about this scenario (assemblies that need to be unloaded, for instance to recompile and load a plugin) points to using AppDomains, yet I haven't seen any samples that demonstrate how to do this correctly.

I have a question: do you think we are ever likely to be able to unload Assemblies from AppDomains?

Fusion contexts always create problems - it's possible for the same assembly to get loaded multiple times in the same appdomain but in different contexts, resulting in types that "look" like they can be shared but really can't. A thorough discussion of the different contexts and how to determine which context a given assembly is in would be useful.

People are always asking loader releated questions in the ASP.NET groups too, specifically about shadow copying, loading from GAC, and loading anything from outside the bin directory of a web app.

From your previous post about unhandled exceptions it sounds like this isn't possible, but is there a way to build a process that recycles individual AppDomains that die from unhandled exceptions? The goal is to not have to tear down the entire process - we just want to tear down and optionally restart the AppDomain that threw the unhandled exception.

This kind of issues and surprises pops up when trying to use AppDomains not as containers for separate 'applications', but as integral part of an application

what aspects of the CLR Loader and AppDomains that folks are most interested in

how much time have you spent on it?

nice to hear... we are waiting to see result

Thanks for the post!

great post!

great post, thanks for the info...