Using AppDomain Isolation to Detect Add-In Failures [Jesse Kaplan]

re: Using AppDomain Isolation to Detect Add-In Failures [Jesse Kaplan]

Udi Dahan — Tue, 01 May 2007 15:51:24 GMT

When you say that other hosts don't support this model, are you including IIS? If so, which version? 6? 7? What about WAS? What about the new Workflow Foundation runtime?

We use AppDomains for the cases when we need the ability to unload assemblies at runtime. But one of the issues we're dealing with is communication from that AppDomain to data that belongs to the primary AppDomain. The threading issue you mentioned above is extremely important to get right in this scenario.

Any advice or patterns you can point out would be most helpful.

re: Using AppDomain Isolation to Detect Add-In Failures [Jesse Kaplan]

CLR Add-In Team — Wed, 02 May 2007 01:51:17 GMT

The sample above only works when the host code is running from the default appdomain: this excludes cases where the host is running in places like IIS or from WAS.

There are ways to get the same functionality in cases there the host isn't running in the default domain. Please stay tuned...

More on Logging UnhandledExeptions from Managed Add-Ins [Jesse Kaplan]

CLR Add-In Team Blog — Thu, 03 May 2007 08:17:56 GMT

Last time we discussed some issues to be aware of when trying to build hosts that are resilient to failures

re: Using AppDomain Isolation to Detect Add-In Failures [Jesse Kaplan]

Michael Vainer — Sun, 07 Oct 2007 19:34:18 GMT

Jesse, if I understand you correctly there is no way to completely recover from add-in child thread error but only log the exception? Will this issue be handled in .Net 3.5 ? It is very important to keep the system running even though one of the add-ins malfunctioning.

re: Using AppDomain Isolation to Detect Add-In Failures [Jesse Kaplan]

Alan Parker — Sat, 10 Nov 2007 05:18:29 GMT

We have a window service that calls on add-in assemblies to do work. These assemblies are loaded in their own AppDomain, can start their own threads which could throw, but then I am able to catch those unhandled exceptions in both the child AppDomain and default AppDomain's UnhandledExceptionEventHandler.

However, I need the service to recover from this. I was hoping to just unload the child domain and start it up again. You suggest that there is a way to restart the application. How would one do that? Any suggestions for dealing with this scenario so we can keep the service running for a long time? How does the IIS WP keep itself alive in similar situation (or does it also unload)?