This project has moved and is read-only. For the latest updates, please go here.

Will be featured at Naples, FL USA Code Camp

Sep 8, 2008 at 9:19 PM
Fantastic work guys, this is really what the .NET framework needs since AppDomain unhandled exception isolation has been removed in 2.0. I will be featuring MEF in my speech entitled "Creating Self-Healing Applications Using App Domains," which I will be giving at the Naples, FL Code Camp on Sept 13, 2008 explaining why App Domains can no longer be used and encouraging the use of the much simpler MEF.
Sep 9, 2008 at 4:33 AM
[ca0abinary] App Domains can no longer be used

This would be a "risk" to a project I currently have in architecture (more here).  Care to elaborate?   Would be interested in supporting links / documentation (preferrably Microsoft) so I can perform an adequate risk assessment.
Sep 9, 2008 at 12:32 PM
Edited Sep 9, 2008 at 1:08 PM
Excuse me if I was vague. AppDomains in general can still be used, but not for the purpose of complete isolation as the CLR will terminate the entire thread if any AppDomain has an UnhandledException error. Therefore if any exception goes uncaught in a third-party plugin it would cause the entire app to be killed which I find undesirable. Interestingly in asynchronous (most notably winforms)  MEF apps this also happens, so there might not be a 100% solution for this.

"In the .NET Framework versions 1.0 and 1.1, an unhandled exception that occurs in a thread other than the main application thread is caught by the runtime and therefore does not cause the application to terminate." ... "In the .NET Framework version 2.0, this backstop for unhandled exceptions in child threads was removed".

It seems there's an (somewhat undocumented) way around this though:
" application hosting the CLR can make use of the ICLRPolicyManager::SetUnhandledExceptionPolicy method to inform the CLR of the unhandled exception policy to be used. Specifying eRuntimeDeterminedPolicy tells the runtime to use its default policy, which is to tear down the process on all unhandled exceptions. Alternatively, eHostDeterminedPolicy can be used to inform the CLR that it should revert to the behavior from the .NET Framework 1.x, where most exceptions are not treated as fatal to the process. The host can then subscribe to the relevant exception-related events on the appropriate AppDomain and can implement its own unhandled exception policy thusly."

Unfortunately that way only works in C++ unmanaged calling managed code...

Unless you do this with your app.config:

<configuration xmlns="">



<legacyUnhandledExceptionPolicy enabled="1" />




Note: The xmlns declaration is vital.

Sep 9, 2008 at 9:34 PM
Thanks for the heads-up; there is tons of information to sift through but this is best known sooner than later.   The CLR Add-In Team did a comprehensive blog on the topic HERE (I found this after your message).  

Suggestion, something you'll want to add to your speech is the distinction between CLRAddIns and MEF codeplex projects.  Seems somewhat fuzzy for someone like me who is just starting in the AppDomain business - for me the biggest distinction is MEF will be a new library in .NET.  starts with "Welcome to the CodePlex site for the Managed Extensibility and Add-In Team. This site will be the home to both samples and tools designed to help you make the best use of the new System.AddIn features in the .Net FX v3.5." notes "The Managed Extensibility Framework (MEF) is a new library in .NET that enables greater reuse of applications and components. Using MEF, .NET applications can make the shift from being statically compiled to dynamically composed. If you are building extensible applications, extensible frameworks and application extensions, then MEF is for you."