Will be featured at Naples, FL USA Code Camp

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.

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.

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".

"...an 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."

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.

http://www.codeplex.com/clraddins 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."

http://www.Codeplex.com/MEF 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."