tag:blogger.com,1999:blog-8942599.post627724310942284622..comments2010-06-27T09:37:21.310-04:00bryanhttp://www.blogger.com/profile/01332614158223702009noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-8942599.post-4181306231305913562010-06-27T09:37:21.305-04:002010-06-27T09:37:21.305-04:00Good point, Yort. I hadn&#39;t tried that out in this post, though it is possible to set up an exception handler for each app domain. I wonder if adding an anonymous delegate to swallow and mark the exception as handled would prevent it from bubbling up to the parent app domain.bryanhttp://www.blogger.com/profile/01332614158223702009noreply@blogger.comtag:blogger.com,1999:blog-8942599.post-81600492662405342382010-06-25T21:42:18.136-04:002010-06-25T21:42:18.136-04:00Unhappily, it appears that from .Net 2.0 on app domains DO NOT isolate unhandled exceptions (do a Google search for the keywords &quot;isolating exceptions in appdomains&quot; for more info.<br /><br />An *unhandled* exception in a secondary app domain will still cause the parent domain to unload and the app to shutdown, unless you enable legacy exception handling in the config file (which is generally not recommended). It also seems there is no way to prevent that behaviour.<br /><br />If you really want to provide that level of isolation you need to host the clr yourself so you can change the way unhandled exceptions are processed. This seems like overkill for a lot of situtations.<br /><br />You can reclaim memory (and unload assemblies) using appdomains like your post suggests though. So other than the suggestion that apddomains isolate exceptions, good article.Yorthttp://www.blogger.com/profile/05345639234245424753noreply@blogger.com