Take the 2-minute tour ×

I've been reading a lot about System.AddIn (a.k.a. Managed Add-in Framework). It lets you activate add-ins in different isolation modes, including separate AppDomains or separate processes.

Most of the articles I've found hint at the fact that process isolation can be used to achieve application reliability, where an add-in can crash with an unhandled exception, but the application will not crash and can unload the offending add-in and keep going.

I have yet to find an article that actually spells out exactly how to do this. I've been trying to figure out through trial and error but so far with everything I've tried, the host application crashes if an add-in throws an unhandled exception. I have each add-in running in its own process, but there seems to be more pieces of the puzzle that I don't understand.

Is it possible to use System.AddIn to create a host that can survive an unhandled exception in one of its add-ins? Are there code samples or articles that spell this out somewhere? If this is not possible with System.AddIn, is there another architecture that would allow for this in a .NET application?

share|improve this question
add comment

1 Answer

Did you find this article?

You let your add-in run in a different AppDomain and listen for uncaught exception raised in this domain.

share|improve this answer
Yes I did read through that. That article describes a way to log which add-in has killed your application, but it does not allow you to save the app from dying. As of .NET 2.0, any unhandled exception in any AppDomain within the process will kill the entire process. AFAIK you have to use separate processes to be able to protect the app from crashing add-ins. –  RationalGeek May 1 '11 at 12:34
add comment

Your Answer


